ПНСТ 344-2018 Интеллектуальные транспортные системы. Автоматическая идентификация транспортного средства и оборудования. Электронная регистрация идентификационных данных транспортных средств. Часть 4. Безопасный обмен данными с использованием асимметричных технологий

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

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

ПРЕДВАРИТЕЛЬНЫЙ

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

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

Интеллектуальные транспортные системы

АВТОМАТИЧЕСКАЯ ИДЕНТИФИКАЦИЯ ТРАНСПОРТНОГО СРЕДСТВА И ОБОРУДОВАНИЯ. ЭЛЕКТРОННАЯ РЕГИСТРАЦИЯ ИДЕНТИФИКАЦИОННЫХ ДАННЫХ ТРАНСПОРТНЫХ СРЕДСТВ

Часть 4

Безопасный обмен данными с использованием асимметричных технологий

(ISO 24534-4:2010, NEQ)

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

Москва

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

2019

ПНСТ 344—2018

Предисловие

1 РАЗРАБОТАН Обществом с ограниченной ответственностью «Научно-исследовательский институт интеллектуальных транспортных систем» (ООО «НИИ ИТС»)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 57 «Интеллектуальные транспортные системы»

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

4 Настоящий стандарт разработан с учетом основных нормативных положений международного стандарта ИСО 24534-4—2010 «Автоматическая идентификация транспортного средства и оборудования. Электронная регистрационная идентификация (ERI) транспортных средств. Часть 4. Безопасный обмен данными с использованием асимметричных технологий» (ISO 24534-4:2010 «Automatic vehicle and equipment identification — Electronic registration identification (ERI) for vehicles — Part 4: Secure communications using asymmetrical techniques», NEO)

Правила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТ Р 1.16—2011 (разделы 5 и 6).

Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: 101990 Москва. Армянский пер., д. 9. стр-1 не Федеральное агентство по техническому регулированию и метрологии по адресу: 109074 Москва. Китайгородский проезд. 0. 7. стр. 1.

В случае отмены настоящего стандарта соответствующая информация будет опубликована в ежемесячном информационном указателе «Национальные стандарты», а также будет размещена на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.fu)

© Стандартинформ. оформление. 2019

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

Содержание

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

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

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

4 Сокращения........................................................................6

5 Концепция системных коммуникаций....................................................6

5.1 Введение.......................................................................6

5.2 Описание составляющих концепции системных коммуникаций...........................6

5.3 Службы безопасности............................................................13

5.4 Описание архитектуры взаимосвязи................................................17

5.5 Интерфейсы....................................................................19

б Требования к интерфейсу............................................................

6.1 Общие положения...............................................................

6.2 Абстрактные определения транзакций..............................................

6.3 Интерфейсы ERT................................................................

Приложение А (обязательное) Модули ASN.1..............................................

Приложение Б (обязательное) Форма протоколов PICS.....................................

Приложение В (справочное) Эксплуатационные сценарии...................................

Библиография.......................................................................80

\A^V

ПНСТ 344—2018

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

Интеллектуальные транспортные системы

АВТОМАТИЧЕСКАЯ ИДЕНТИФИКАЦИЯ ТРАНСПОРТНОГО СРЕДСТВА И ОБОРУДОВАНИЯ.

ЭЛЕКТРОННАЯ РЕГИСТРАЦИЯ ИДЕНТИФИКАЦИОННЫХ ДАННЫХ ТРАНСПОРТНЫХ СРЕДСТВ

Часть 4

Безопасный обмен данными с использованием асимметричных технологий

Intelligent transport systems. Automatic vehicle and equpment identification. Electronic registration of identification data for vehicles.

Part 4. Secure communications using asymmetrical techniques

Срок действия — с 201^—06—01 до 2022—06—01

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

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

- при электронной идентификации местных и иностранных ТС органами государственной власти:

• производстве ТС, обслуживании во время эксплуатационного срока ТС и идентификации при его окончании:

- установлении срока службы (управлении жизненным циклом ТС);

• адаптировании данных ТС (например, для международных продаж);

• идентификации в целях обеспечения безопасности;

• сокращении числа совершаемых преступлений;

• при оказании коммерческих услуг.

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

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

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

ПНСТ 343—2018 Интеллектуальные транспортные системы. Автоматическая идентификация транспортного средства и оборудования. Электронная регистрация идентификационных данных транспортных средств. Часть 3. Архитектура

ПНСТ 344—2018 Интеллектуальные транспортные системы. Автоматическая идентификация транспортного средства и оборудования. Электронная регистрация идентификационных данных. Часть 4. Безопасный обмен данными с использованием асимметричных технологий

ПНСТ 345—2018 Интеллектуальные транспортные системы. Автоматическая идентификация транспортного средства и оборудования. Электронная регистрация идентификационных данных. Часть 5. Безопасный обмен данными с использованием симметричных технологий

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

ЛИСТ 344—2018

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

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

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

3.1 авторизация (authorization): Предоставление прав, включающее обеспечение доступа на основе прав доступа.

3.2 активная угроза (active threat): Угроза преднамеренного несанкционированного изменения состояния системы.

3.3 аутентификация объекта (entity authentification): Подтверждение того, что предприятие является заявленным.

3.4 безотказность (non-repudiation): Ни одно из подразделений, участвующих в сообщении, не может полностью или частично наложить запрет на участие в сообщении.

3.5 беспроводной интерфейс (air interface): Интерфейс без проводника между бортовым оборудованием и считывателем/опросным листом, посредством которого соединение бортового оборудования (ОВЕ) со считывателем/запросчиком осуществляется с помощью электромагнитных сигналов.

3.6 бортовой автор ERI (onboard ERI writer): Автор ERI, который является частью встроенного оборудования ERI.

3.7 верификатор (verifier): Объект, который является или представляет объект, требующий аутентифицированного удостоверения транспортного объекта.

3.8 внешняя запись ERI (external ERI reader): считыватель ERI (ERI writer): Считыватель ERI. который не является частью ее встроенного оборудования.

Примечания

1 Внешний считыватель ERI на установлен внутри или снаружи транспортного средства.

2 Есть различив между ближним (DSRC) и удаленными внешними авторами. Считывающее устройство для приближения может быть, например. РСО. с учетом [1]. Внешний считыватель ERI может быть частью придорожного оборудования, ручного оборудования или мобигъного оборудования. Удаленная внешняя запись ERI может быть частью бэк-офисного оборудования (ВОЕ).

3.9 время жизни (lifetime): Период времени, в течение которого существуют предмет оборудования и функции.

3.10 встроенное оборудование ERI (onboard ERI equipment): Оборудование, установленное внутри или снаружи транспортного средства и используемое для целей ERI.

Примечание — Встроенное оборудование ERI содержит ERT и может также содержать дополнительные устройства связи.

3.11 встроенный считыватель ERI (onboard ERI reader): Считыватель ERI является частью встроенного оборудования ERI.

Примечание — Встроенный считыватель ERJ может быть, например, устройством с бесконтактным соединением РСО.

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

Примечание — В настоящем стандарте термин «вызов» используется также в том случав, если ERT не имеет возможности шифрования и копируется без секретной информации.

3.13 главный (principal): Объект, чья личность может быть аутентифицирована.

3.14 данные ERI (ERI data): Данные идентификации транспортного средства, которые могут быть получены из ERT. состоящей из идентификатора и возможных дополнительных данных транспортного средства.

3.15 держатель ERT (ERT): Юридическое или физическое лицо, имеющее ERT.

Прим еча нив — Держателем ERT может быть, например, держатель регистрационного номера или владелец, оператор или хранитель транспортного средства.

3.16 дополнительные данные транспортного средства (additional vehicle data): Данные электронной регистрации идентификационных данных ERI в дополнение к идентификатору транспортного средства.

3.17 запись ERI (ERI writer): Устройство, используемое для непосредственного или косвенного ввода данных ERI в ERT путем вызова транзакций ERI.

Прим еча н и в — Если копир ERI обменивается блоками данных протокола ERI непосредственно по каналу передачи данных с ERT, его тахже называют ERR. Если он обменивается данными через один или несколько узлов, только последний узел в этой последовательности называется ERR. Как следствие внешний писатель ERI может в зависимости от конфигурации на борту действовать для некоторых транспортных средств как ERR.

3.18 защита (security): Защита информации и данных для того, чтобы, с одной стороны, неавторизованные лица или системы не могли их читать или модифицировать, а с другой, уполномоченным лицам или системам был предоставлен доступ к ним.

3.19 заявитель (claimant): Объект, являющийся или представляющий собой принципал для целей аутентификации, включая функции, необходимые для участия е обмене аутентификацией от имени принципала.

3.20 идентификация (identification): Действие или акт установления личности.

Примечание —См. также: идентификация транспортного средства.

3.21 ключ (key): Последовательность символов, управляющая работой криптографического преобразования (например, шифрование, дешифрование, вычисление функции криптографической проверки. генерация подписи или проверка подписи).

3.22 ключ общедоступного шифрования (public encipherment key): Открытый ключ, который определяет преобразование открытого шифрования.

3.23 ключ частной подписи (private signature key): Закрытый ключ, определяющий преобразование частной подписи.

3.24 контроль доступа (access control): Предотвращение несанкционированного использования ресурса, е том числе несанкционированным образом.

3.25 конфиденциальность (confidentiality): Информация, не предоставляемая или не раскрываемая неаеториэоеанным лицам, организациям или процессам.

3.26 конфиденциальность (privacy): Право отдельных лиц контролировать или влиять на сбор и хранение информации, относящейся к данным лицам, включая ее адресацию.

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

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

3.28 маскарад (masquerade): Представлять один объект е качестве другого.

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

3.30 односторонняя аутентификация (unilateral authentication): Действие, позволяющее идентифицировать один объект для удостоверения личности другого, но не наоборот.

3.31 оператор системы ERI (ERI transaction): Устройство записи ERI. используемое для прямого или косвенного ввода данных ERI в ERT путем вызова транзакций ERI.

Прим еча н и е — Если копир ERI обменивается блоками данных протокола ERI непосредственно по каналу передачи данных с ERT, его тахже называют ERR. Если он обменивается данными через один или несколько узлов, только последний узел в этой последовательности называется ERR. Как следствие внешний писатель ERI в зависимости ог конфигурации на борту может действовать для определенных транспортных средств как ERR.

ЛИСТ 344—2018

3.32 орган власти (authority): Организация, зарегистрированная согласно действующему законодательству для идентификации транспортного средства с использованием электронной регистрации идентификационных данных ERI.

3.33 от конца до конца {end-to-end encipherment): Шифрование данных внутри или в исходной конечной системе с соответствующей дешифровкой, происходящей только внутри или в конечной системе.

3.34 открытый текст (cleartext): Данные, семантическое содержание которых изложено доступно.

3.35 открытый ключ проверки (public verification key): Открытый ключ, определяющий преобразование общественного подтверждения.

3.36 отличительный идентификатор (distinguishing identifier): Информация, которая однозначно отличает тип.

3.37 пароль (password): Конфиденциальная информация аутентификации, обычно состоящая из строки символов.

3.38 пассивная угроза (passive threat): Угроза несанкционированного раскрытия информации без изменения состояния системы.

3.39 периодическое испытание транспортного средства (periodic motor vehicle test): Обязательный периодический (например, ежегодный) тест на пригодность транспортного средства после определенного срока эксплуатации или свидетельство о прохождении такого испытания.

3.40 повторная атака (replay attack): Маскарад, предполагающий использование ранее переданных сообщений.

3.41 полномочия (credentials): Данные, передающиеся для установления личности лица.

3.42 порядковый номер (sequence number): Параметр времени, значение которого соответствует заданной последовательности, не повторяющейся в течение определенного периода времени.

Примечания

1 В случае высокой безопасности ERT является типом защищенного прикладного модуля SAM.

2 ERT может быть отдельным устройством или встроено в бортовое устройство, которое также предоставляет другие возможности (например. DSRC-связь).

3.43 промежуточный центр сертификации (intermediate certification authority): Центр сертификации. для которого сертификаты открытого ключа выдаются центром сертификации высшего уровня.

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

3.44 расшифровка дешифрования (decipherment decryption): Разворот соответствующей обратимой шифровки.

3.45 регистрирующий орган транспортных средств (registration authority of transport vehicles): Орган, ответственный за регистрацию и ведение записей транспортных средств.

Примечание — Орган может предоставлять записи транспортных средств аккредитованным организациям.

3.46 регистрирующий орган данных ERI (registration authority of ERI data): Организация, ответственная за запись данных ERI и данных безопасности в соответствии с местным законодательством.

Примечание — Функции регистрирующего органа данных ERI могут быть такими же. как и функции регистрирующего органа для транспортных средств.

3.47 свидетельство регистрации (registration certificate): Документ регистрации транспортного средства (документ или смарт-карта), выданный регистрирующим органом транспортных средств, в котором зарегистрированы транспортное средство, его владелец или арендатор.

3.48 сертификат открытого ключа (public key certificate): Информация открытого ключа одного лица, освидетельствованная центром сертификации и. следовательно, абсолютно недоступная другим лицам.

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

3.49 случайное число (random number): Параметр времени, значение которого непредсказуемо.

3.50 список контроля доступа (access control list): Список сущностей вместе со своими правами доступа, которым разрешен доступ к ресурсу.

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

3.51 транспортный идентификатор {vehicle identification): Действие или акт идентификации транспортного средства.

Примечание — Верификатор включает в себя функции, необходимые для участия в обмене аутентификацией.

3.52 угроза (threat): Потенциальное нарушение безопасности.

3.53 устройство чтения ERI (ERI reader): Устройство, используемое для прямого или косвенного считывания данных ERI из ERT путем вызова транзакций ERI.

Примечание —Если считыватель ERI обменивается блоками данных протокола ERI напрямую по каналу передачи данных с ERT. его также называют ERR. Если он обменивается данными через один или несколько узлов, только последний узел в этой последовательности называется ERR. Как следствие внешний считыватель ER1 в зависимости от конфигурации на борту может выступать для определенных транспортных средств в качестве ERR.

3.54 хеш-код (hash-code): Строка битов, которая является выводом хеш-функции.

3.55 хеш-функция (hash-function): Функция, отображающая строки битов в строки фиксированной длины битов, удовлетворяющие следующим двум свойствам:

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

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

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

3.56 целостность данных (data integrity): Данные, которые не изменены или уничтожены несанкционированным образом.

3.57 центр сертификации (certification authority): Физическое или юридическое лицо, уполномоченное создавать сертификаты открытых ключей.

3.58 центр сертификации высшего уровня (top-level certification authority): Сертифицирующий орган, сертификаты которого могут быть проверены, так как его общедостулный(е) ключ(и) проверки безопасности записывается(ются) как данные только для чтения в ERT до момента ее настройки или ввода в эксплуатацию.

3.59 цифровая подпись (digital signature, signature): Данные или криптографическое преобразование блока данных, идентифицирующие источник для получателя блока данных, а также обеспечивающие целостность блока данных и защиту от подделки, например получателем.

Прим еча нив — См. также «криптография» (3.29).

3.60 частный ключ (private key): Ключ асимметричной пары ключей объекта, который должен быть использован только этим объектом.

Примечание — В случае асимметричной системы подписи частный ключ определяет преобразование подписи: при асимметричной системе шифрования частный ключ определяет преобразование дешифрования.

3.61 частный ключ дешифрования (private decipherment key): Закрытый ключ, определяющий приватное преобразование дешифрования.

3.62 число ERT (ERT number): Номер, присвоенный и записанный в ERT. который выступает в качестве уникального идентификатора ERT.

П р и м еча н и е — Предполагается, что номер ERT записывается в ERT во время его изготовления и после его записи не может быть изменен.

3.63 шифрованный текст (chipertext): Данные, полученные с помощью шифрования, семантическое содержание которых недоступно.

3.64 электронный регистратор чтения ERR (electronic registration reader. ERR): Устройство, используемое для чтения или чтения/залиси данных из/в электронную регистрационную метку ERT.

Примечания

1 ERR связывается напрямую, т. в. через линию данных OSI. с ERT.

2 ERR также может быть считывателем и/или записывающим устройством ERI либо выступать в качестве ретранслятора в обмене между протоколами данных ERI. ERT и считывающим устройством ERI.

ПНСТ 344—2018

3.65 электронная регистрация идентификационных данных; ERI (electronic registration identification}: Действие или акт идентификации транспортного средства с помощью электронных средств.

3.66 электронная регистрационная метка ERT (electronic registration tag. ERT): Встроенное устройство ERI. содержащее данные ERI. включая соответствующие внедренные положения безопасности и один или несколько интерфейсов для доступа к этим данным.

4 Сокращения

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

AEI — автоматическая идентификация оборудования (automatic equipment identification};

AES — расширенный стандарт шифрования (advanced encryption standard):

ASN.1 — абстрактная синтаксическая нотация (Abstract Syntax Notation One);

AVI — автоматическая идентификация транспортных средств (automatic vehicle identification);

ВОЕ — бэк-офисное оборудование (back office equipment);

EN — европейские нормы [Europaische Norm (German). European Standard (English)];

ENV—европейский предварительный стандарт [Europaische Norm Vorausgabe (German). European Pre-Standard (English)]

ERI — электронная регистрация идентификационных данных (electronic registration identification);

ERR — электронный регистрационный считыватель (electronic registration reader):

ERT — электронная регистрационная метка (electronic registration tag);

EU — Европейский союз (European Union);

IEC — Международная электротехническая комиссия (International Electrotechnical Commission);

ISO — Международная организация no стандартизации (International Organization for Standardization);

OBE — бортовое оборудование (on board equipment);

OSI — объединение открытых систем (Open System Intercorrection};

PICS — заявления о соответствии реализации протокола(-ов) [Protocol Implementation Conformance Statement(s)]:

PIN — персональный идентификационный номер (personal identification number);

SAM — модуль приложения безопасности (secure application module};

VIN — идентификационный номер транспортного средства (vehicle identification number).

5 Концепция системных коммуникаций

5.1 Введение

В настоящем подразделе содержится введение в контекст, согласно которому данные ERI и данные безопасности могут считываться или записываться в ERT. позволяющую идентифицировать ТС. а также представлены варианты, которые могут быть использованы при фактической реализации. Нормативные требования для интерфейсов прикладного уровня приведены в разделе 6 и приложении А. Приложение Б содержит форму, определяющую ограничения фактической реализации протокола связи.

5.2 Описание составляющих концепции системных коммуникаций

5.2.1 Идентификация регистрации транспортного средства

Электронная регистрация идентификационных данных ERI — это действие или акт идентификации ТС с помощью электронных средств.

Идентификатор, используемый для идентификации ТС. называется идентификатором ТС.

Примечания

1 Предпочтительным вариантом идентификатора ТС является VIN. который назначен его изготовителем (см. [1]). кроме того, поддерживаются альтернативы (подробнее см. ПНСТ 343—2018).

2 Более подробная информация об идентификаторе ТС и данных ER1 приведена в ПНСТ 343—2018.

8 настоящем стандарте в качестве однозначного идентификатора отличительной черты испольэо-вака комбинация уникального идентификатора ТС и уникального номера ERT.

5.2.2 Концепция системы и поддерживаемые интерфейсы

На рисунке 1 представлены интерфейсы, для которых прикладной уровень указан в настоящем стандарте.

Рисунок 1 — Концепция системы и поддерживаемые интерфейсы

встроенный компонент, обеспечивающий безопасную среду для данных ERI и данных безопас* ности. называется электронной регистрационной меткой ERT.

Примечание — Исполнитель может интегрировать другие положения (например, дополнительные положения о связи) в ERT при соблюдении ев безопасности.

8 зависимости от своих возможностей ERT адаптируется к конкретному ТС на трех последовательных этапах (см. рисунок В.2 приложения В):

а) во-первых. ERT настроена с идентификатором ТС приложения 6 и, при необходимости, с дополнительными данными о ТС. Этот шаг может быть выполнен только один раз в течение жизни ERT. Пользовательская настройка не позволяет предоставлять услуги шифрования или подписи ERT;

б) во-вторых, регистрирующий орган может быть текущим регистрирующим органом ТС. добавив его данные безопасности. Регистрирующий орган может изменить свои данные о безопасности путем повторного ввода данных в действие. При поддержке ERT ввод в эксплуатацию позволяет предоставлять услуги конфиденциальности и аутентификации ERT, например необходимые ключи безопасности. Если ключ не указан, соответствующие службы не будут включены.

Примечание — Большинство смарт-карт принадлежат и контролируются одним эмитентом на протяжении всей их жизни, однако в отношении ERT ситуация иная. Когда продажа ТС осуществлена в другой стране. ERT попадает под контроль нового регистрирующего органа, поэтому будут оформлены новая немодная табличка и новый регистрационный сертификат для ТС. Затем ERT будет повторно введена в эксплуатацию:

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

Примечание — Учитывая особенности регистрации ТС в разных странах, можно вкгеочить различные варианты приведения дополнительных данных о ТС (подробнее см. ПНСТ 343—201В).

Положения о бортовой связи должны быть способны передавать данные из/в ERT без изменения этих данных.

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

Устройство связи может быть связано с внешним считывающим устройством или считывателем проксимити, со считывателем и/или записывающим устройством с малым радиусом действия или с удаленным бэк-офисным оборудованием (ВОЕ).

Устройство связи, которое осуществляет связь с внешним считывающим устройством/считывате-лем ERI. действует как ретранслятор между этим внешним считывающим устройством/считывателем ERI и встроенным устройством чтения/записи ERI. Устройство связи также может быть использовано для других приложений.

5.2.3 Используемые роли

В настоящем стандарте выделены следующие «роли» для физических или юридических лиц:

- производители, назначающие номер VIN или шасси для каждого ТС. которое они создают. Из* готовитель может также настроить ERT для конкретного ТС:

* регистрирующие органы (в отношении данных ERI). которые могут:

- назначить новое ТС (в случае дефектов) и настроить ERT (например, в случае дефектов или дооснащения).

Примечание — Регистрирующий орган может присвоить новый идентификатор ТС (например, когда номер на шасси поврежден). Затем он добавит новый идентификатор на шасси и зафиксирует его в ERT (причем идентификатор ТС не может быть перезаписан);

* поручительство себя в качестве регистрирующего органа для ТС:

* продоставление другим органам власти допуска к данным ERI:

* предоставление разрешения держателю ERT предоставлять другим поставщикам услуг доступ к данным ERI. которые отвечают за регистрацию дополнительных данных о ТС в ERT в соответствии с местным законодательством (подробнее см. ниже).

Примечания

1 Ожидается, что регистрирующий орган е отношении данных ERI является тем же органом, который хранит официальный реестр, в котором указано ТС.

2 Предполагается, что каждое ТС указано в регистре, который содержит идентификатор ТС и дополнительные данные, относящиеся к ТС. Причем этот регистр также идентифицирует ответственного за ТС (например, его владельца, оператора, хранителя, арендатора и/или водителя):

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

- центр сертификации высшего уровня и

> один промежуточный центр сертификации или более.

Примечания

1 Центр сертификации не будет напрямую связываться с ERT. Их сертификаты используют производители и регистрирующие органы.

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

- органы власти, уполномоченные регистрирующим органом для считывания данных ERI с ТС (например, потому, что они имеют право делать это в силу действующего законодательства):

- дополнительные поставщики услуг (государственные или частные), которые предоставляют услугу. требующую электронной идентификации ТС и/или данных сертифицированного ТС. Владелец ERT может разрешать или не разрешать дополнительному поставщику услуг читать идентификатор ТС и дополнительные данные ТС;

- держатели ERT. которые могут быть, например, владельцем ТС. оператором или хранителем ТС.

Даже е тех случаях, когда поддерживается конфиденциальность данных ERI, владелец ERT имеет право читать ERI в своем ТС и разрешать другим поставщикам услуг читать данные идентификатора ТС. PIN-код. выданный регистрирующим органом держателю ERT, обеспечивает необходимый контроль доступа для держателя ERT.

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

5.2.4 Коммуникационный контекст для чтения

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

Бортовой или внешний считыватель ERI используется для чтения данных из ERT. встроенный считыватель ERI взаимодействует непосредственно с ERT и напрямую или косвенно связывается с ERT. например: непосредственно в случае карманного считывателя или интегрированного устройства ERI или опосредованно через бортовой модуль связи и встроенный считыватель ERI. Бортовой модуль связи может быть также использован для других приложений.

Рисунок 2 — Коммуникационный контексг для чтения из ERT

Сенсорная система (вне рамок настоящего стандарта) может быть использована для запуска внешнего считывателя ERI при фиксировании ТС. которое необходимо идентифицировать.

Лица, которые могут считывать данные ERI из ERT. представлены в 5.2.3. Права доступа различных объектов описаны в 5.3.5.1.

владелец ERT может пожелать иметь доступ к данным ERI по различным причинам:

* для проверки правильности данных ERI;

- получения аутентифицированного (подписанного) идентификатора ТС или данных ERI. которые будут использованы для другого приложения:

- проверки списка контроля доступа (см. 5.3.5) при его наличии в ERT:

- проверки исторических данных ERI и/или исторических данных ввода в эксплуатацию при их наличии в ERT.

Оборудование, используемое органом власти, дополнительным поставщиком услуг или держателем ERT в своем офисе (т. е. в закрытом помещении), называется бэк-офисным оборудованием (вОЕ).

Распределение функций между ВОЕ и внешним считывателем ERI выходит за рамки настоящего стандарта.

5.2.5 Коммуникационный контекст для написания

На рисунке 3 представлен контекст связи для записи данных в ERT.

Бортовую или внешнюю запись ERI используют для записи данных в ERT. Встроенный коммуникатор ERI напрямую связывается с ERT. Внешняя запись ERI может напрямую или косвенно связываться с ERT, например: непосредственно в случае карманного записывающего устройства либо интегриро-ванного устройства ERI или опосредованно через бортовой модуль связи и встроенную запись ERI. Бортовой модуль связи также может быть применен для других приложений.

Рисунок 3 — Коммуникационный контекст для записи 8 ERT

Различные объекты, которые могут записывать данные ERI (безопасности) в ERT. описаны в 5.2.3. Права доступа различных объектов описаны в 5.3.5.2.

Центры сертификации предоставляют сертификаты открытого ключа для производителей и регистрирующих органов. Сертификаты используются при записи данных в ERT как доказательство подлинности (подписанных) данных, полученных от производителя или регистрирующего органа. Сертификаты также применяются дпя проверки подлинности данных ERI при считывании.

Регистрирующий орган наделяет полномочиями держателя ERT путем предоставления пароля (PIN). Затем владелец ERT может предоставить дополнительному поставщику услуг доступ к данным ERI.

Распределение функций между ВОЕ и внешним устройством ERI выходит за рамки настоящего стандарта. Регистрирующий орган может поручить писателю действовать от его имени или использовать его. например: писатель является ретранслятором для удаленного письма из своего бэк-офиса.

5.2.6 Поддерживаемые уровни ERT

Предполагается, что разные пользователи могут иметь разные требования к ERI. поэтому в настоящем стандарте представлена поддержка различных уровней обслуживания возможностей ERT.

На рисунке 4 представлено описание различных уровней возможностей ERT (см. также профили соответствия протокола (PICS) в приложении Б).

Для ЕНГ, паааержянищбй вхфийемдеапьноегь «Л» доступа: -других органов;

* дополнктжъных поопаицам уолуг

Омоаиыв мрмкт:

Твгыю U - Талые чтмм

Тояме чтанпа с долагмггальныым дмншмеТС

ЧгамиЛажаь

баападтверкдвмея

Рисунок 4 — Поддерживаемые уровни ERT

Различают следующие основные варианты (вариант в наконечнике стрелок также включает в себя возможности одного из хвостов стрелки):

- только id — только чтение: это простейший вариант ERT. Идентификатор ТС записывается толь* ко один раз. и другая информация не может быть добавлена. В этом случае считыватель ERI может считывать идентификатор ТС непосредственно из ТС (ERT):

- только для чтения с дополнительными данными о ТС: в этом случае ERT может также содержать дополнительные данные о ТС (см. ПНСТ 343—201 б). Однако все данные могут быть записаны только один раз в течение жизни ERT.

По соображениям безопасности данные могут также содержать подпись созданного объекта;

- чтение/запись без подтверждения аутентификации или конфиденциальности: в этом случае ERT содержит идентификатор ТС плюс дополнительные данные о ТС. При необходимости эти дополнительные данные могут быть обновлены;

- чтение/запись с аутентификацией: в этом случае ERT также предоставляет услуги аутентификации. ERT может проверять подпись, прикрепленную к записанным в нее данным. Если предусмотрено. ERT может также присоединить подпись к данным, которые она отправляет в считыватель ERI. Затем считыватель ERI может проверить, что полученные данные проистекают из подлинной ERT. а не из фальшивой.

Примечание — Регистрирующий орган может отключить возможности подписи ERT. но не ее проверки:

- чтение/запись с конфиденциальностью: в этом случае ERT может предоставлять услуги конфиденциальности. ERT может дешифровать данные безопасности, зашифрованные записью ERI. Если предусмотрено. ERT может также шифровать данные, которые отправляет в считыватель ERI. Эти данные могут быть интерпретированы только теми сторонами, которые имеют соответствующий частный ключ дешифрования.

Прим еча нив — Регистрирующий орган может отключить возможности шифрования ERT. но не возможности дешифрования:

- чтение/запись с использованием как аутентификации, так и конфиденциальности: в этом случае ERT обеспечивает как аутентификацию, так и услуги конфиденциальности.

8 дополнение к этим основным вариантам можно различать различные подварианты, например

ERT:

- чтения/записи, которая также ведет журнал исторических данных, т. е. предыдущих операций записи;

• с услугами конфиденциальности, для которых регистрирующий орган может также наделить полномочиями другие органы для доступа к данным ERI;

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

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

5.2.7 Уровни безопасности и функциональная совместимость

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

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

В таблице 1 представлены различные комбинации, когда ERT и считыватель ERI имеют разные криптографические возможности.

Таблица 1 — Взаимодействие между ERT и считывателями ERI

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

Пример — Когда ТС импортируется из страны с высоким уровнем конфиденциальности в страну с менее строгим уровнем защиты конфиденциальности (следовательно, использованы читатели, не имеющие возможности расшифровки), тогда регистрирующие органы могут отключить возможности дешифрования ЕПТ при ее вводе в эксплуатацию.

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

Что касается функциональной совместимости между ERT и писателями ERI. приоритет отдается безопасности выше уровня поддержки международных (повторных) продаж. Так как регистрирующий орган может заменить ERT, это не считается серьезным ограничением. Основным принципом написания является то. что автор и, следовательно, регистрирующий орган могут определять возможности ERT. и на основании этого регистрирующий орган может решить принять данную ERT или заменить ее на соответствующую предъявляемым требованиям.

Примечание — Если регистрирующий орган не принимает определенную ERT. то регистрирующий орган должен заменить ее на приемлемую и осуществить настройку в дальнейшем по мере необходимости.

Взаимодействие ERT и писателей ERI с различными уровнями возможностей показано в таблице 2.

Таблица 2 — Взаимодействие между ERT и авторами ERI

Ответственный регистрирующий орган должен принять или не принять конкретную ERT в пределах своей юрисдикции, т. е. регистрирующий орган может принять решение относительно роли поручителя в конкретной ERT.

5.3 Службы безопасности

5.3.1 Предположения

Концепция безопасности обмена данными между ERT и считывателем или автором ERf основана на следующих предположениях:

- использование ERT может быть обязательным и. следовательно, должно быть устойчивым к мошенничеству. ERT (см. {2]) должна быть устойчивой к активным угрозам (например, изменение, воспроизведение сообщений, вставка ложных сообщений и маскировка);

- чтение ERT должно быть пригодным в качестве юридического доказательства (неотказуемости).

П р и м вча ни© — Для этого может потребоваться спецификация профиля защиты (включая достаточный уровень обеспечения оценки. EAL) для ERT {см. [3]). Однако такая спецификация выходит за рамки настоящего стандарта:

- ERI должна иметь возможность обеспечить высокий уровень защиты частной жизни (т. е. возможности легко отслеживать модели мобильности ТС. и. следовательно, его обычного водителя не должно быть). Как следствие ERT также должна быть устойчивой к пассивным угрозам;

- ERI должна иметь возможность предусматривать меры защиты, для того чтобы предотвратить использование ERI для запуска атаки на ТС;

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

Пример— Чтение данных ТС со скоростью 180 км/ч в пределах 10-метровоао диапазона считывания должно быть достигнуто е течение 200 мс.

5.3.2 Аутентификация объекта при чтении данных ERI

Доверие к подлинности чтения данных ERI зависит от следующих аспектов аутентификации, которые должны быть выполнены для того, чтобы полностью доверять чтению:

а) ERT настраивается с достоверным идентификатором ТС и прикрепляется к ТС;

б) ERT не может быть удалена из ТС. не делая его неработоспособным:

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

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

д) если данные ERI правильно прочитаны из подлинной ERT по конкретному запросу, сложно впоследствии будет оспаривать, что эти данные не прочитаны из этого компонента по этому запросу (неот-казуемостъ). что достигается путем подписания данных ERI вместе с кодом вызова, предоставляемым считывателем ERI.

Примечания

1 Пункт 5.3.2 касается только перечислений г)—д). Пункт б) указан в ПНСТ 342—2018.

2 Использование терминологии, приведенной в перечислениях г) и д) (4]. поддерживается путем применения двухстороннего одностороннего механизма аутентификации. Единстввнность/своеврвменность контролируется путем генерирования и проверки случайного числа, отправленного считывателем ERI (верификатором) в ERT (заявитель).

5.3.3 Конфиденциальность при чтении данных ERI

В настоящем стандарте поддерживается конфиденциальность, предоставляя данные ERI в зашифрованном виде. Зашифрованные данные ERI могут находиться е свободном доступе, но будут расшифрованы и интерпретированы только уполномоченными лицами/оборудоеанием (сквозная шифровка).

Для того тобы запретить использование зашифрованных данных ERI е качестве псевдонима, к данным ERI перед шифрованием добавляется порядковый номер.

Примечание — Конфиденциальность 8 технических терминах обеспечивается с помощью асимметричных ключей. В случае операций чтения ERT использует общедоступный ключ шифрования органа, зарегистрированного в ERT регистрирующим органом или владельцем ERT (для дополнительного поставщика услуг). В случае операций записи конфиденциальность достигается с помощью общедоступного ключа шифрования, который может быть получен из ERT. Затем данные, которые нужно записать, могут быть дешифрованы только с помощью секретного ключа дешифрования ERT.

5.3.4 Ключи для аутентификации и конфиденциальности

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

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

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

В соответствии с настоящим стандартом регистрирующий орган изменяет свой общедоступный ключ шифрования, ключ частной подписи и PIN-код для держателя ERT. Это может быть, например, частью периодического испытания ТС.

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

5.3.5 Контроль доступа к данным ERI

5.3.5.1 Контроль доступа к чтению

а) Объекты с доступом чтения

Следующие три типа объектов могут потребовать доступа к данным ERI;

- органы власти;

• авторизованные поставщики услуг.

- держатель ERT.

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

• идентификатор:

. общедоступный ключ шифрования и идентификатор ключа;

- указание на полномочия данного лица.

Открытый ключ шифрования использован для шифрования случайного секретного ключа, данных ERI. отправленных считывателю ERI.

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

б) Доступ для чтения для уполномоченных органов

Если ERT использует возможности шифрования, регистрирующий орган может разрешить полно* мочия для считывания данных ERI путем записи ее идентификатора, ключа общедоступного шифрова-ния и идентификатора ключа в список управления доступом ERT {см. 5.3.5.2).

Читатель ERI уполномоченного органа может иметь конфиденциальный доступ к данным ERI. предоставляя идентификатор этого органа. Затем ERT зашифрует данные ERI с помощью своего общедоступного ключа шифрования.

в) Доступ для несанкционированного чтения органами власти

Орган власти, которому не разрешено считывать данные ERI. не должен указывать идентификатор объекта в его запросе на чтение. Затем ERT шифрует данные ERI с помощью общедоступного ключа шифрования регистрирующего органа ТС.

Затем для дешифрования данных ERI требуется частный ключ дешифрования в регистрирующем органе ТС. что может быть выполнено несколькими способами (которые не входят в рамки настоящего стандарта):

- считыватель ERI можно ввести в эксплуатацию, предоставив секретный ключ дешифрования регистрирующего органа, например SAM. и в этом случае считыватель может дешифровать данные ERI;

- локальный (регистрирующий) орган может иметь этот закрытый ключ и затем расшифровать данные ERI. полученные читателем;

• регистрирующему органу ТС может быть предложено расшифровать данные ERI.

Прим вче н и е — Процедуры сотрудничества между регистрирующими органами выходят за рамки настоящего стандарта.

г) Доступ для чтения, предоставляемый авторизованным поставщикам услуг

Доступ к данным поставщика услуг контролируется путем добавления его идентификатора, открытого ключа шифрования и идентификатора ключа в список управления доступом в ERT. Затем считыватель этого поставщика услуг может быть введен в эксплуатацию с помощью соответствующего частного ключа дешифрования.

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

д) Доступ для чтения для держателя ERT

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

Использование только vehicleld нарушает требование о том, что ERI не будет легко использоваться для запуска атаки на ТС. Успех попытки считывания данных с использованием только Vehicleld в качестве информации относительно аутентификации может затем применяться в качестве такого триггера. Использование PIN-кода снижает этот риск.

5.3.5.2 Контроль доступа к записи

а) Объекты с доступом для записи

Доступ к записи может потребоваться следующим типам объектов:

- изготовителям и регистрирующим органам для настройки ERT для конкретного ТС;

• регистрирующим органам для ввода в эксплуатацию и обновления данных ERI или данных безопасности;

- владельцу ERT.

б) Доступ к записи для настройки производителями и регистрирующими органами

Настоящий стандарт поддерживает настройку ERT для конкретного ТС производителем или регистрирующим органом.

Настройка ERT для конкретного ТС осуществляется путем написания идентификатора ТС и в конечном счете внесения дополнительных данных ТС (например, даты регистрации, регистрационного номера, типа двигателя и т. д.) в этот компонент.

ERT можно настраивать только один раз в течение срока ее эксплуатации, а идентификатор ТС в ERT не может быть изменен ни при каких обстоятельствах.

Примечание — Это может быть выполнено, например, изготовителем во время сборки ТС регистрирующим органом, при необходимости, при замене ERT (например, из-за дефекта) или ее модификации.

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

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

- если сертификат открытого ключа выдается промежуточным центром сертификации, то сертификатом открытого ключа считается сертификат, выданный центром сертификации высшего уровня.

Примечания

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

2 Так как требуется, чтобы данные, которые должны быть записаны в ERT. были выданы официальным регистрирующим органом (и содержать действительный идентификатор ТС), отсутствует необходимость санкционировать пишущее оборудование. Канал связи, используемый для обмена данными ERI от ВОЕ регистрирующего органа е ERT. может быть небезопасным.

в) Дополнительный доступ для записи в регистрирующие органы

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

> поручить себя в качестве регистрирующего органа ТС;

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

Примечание — Эгогсертификат также включает идентификатор ТС:

- добавить или изменить свой общедоступный ключ шифрования, необходимый для шифрования данных ERI (при сохранении конфиденциальности);

- разрешить другим органам, добавляя их идентификатор, использовать ключ общедоступного шифрования и идентификатор ключа в списке контроля доступа ERT (если необходимо поддерживать конфиденциальность);

- добавить или изменить PIN-код, выданный держателю ERT (при сохранении конфиденциальности).

Примечание —Каким образом и когда регистрирующий орган посылает держателю ERT (новый) PIN-код, выходит за рамки настоящего стандарта:

- изменить данные о дополнительном ТС (например, его регистрационный номер и цвет, тип двигателя и т. д.) согласно требованиям или разрешениям местного законодательства.

Доступ к записи получается путем передачи одного или двух сертификатов открытого ключа, как описано в предыдущем разделе.

г) Доступ к записи для держателей ERT

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

- для дополнительного поставщика услуг путем записи идентификатора, общедоступного ключа шифрования и идентификатора ключа этого поставщика услуг в ERT;

• бортовые приложения/оборудование. которые должны проверять или аутентифицировать дан* ные ERI, записывая идентификатор, общедоступный ключ шифрования и идентификатор ключа в ERT.

Для того чтобы получить доступ к записи, владелец ERT должен идентифицировать себя как дер* жателя ERT. содержащего данные ERI. и с этой целью использует идентификатор ТС и пароль (PIN), полученный от регистрирующего органа.

П р и м вча нив — Каким образом и когда владелец ERT получает этот пароль (PIN), выходит за рамки настоящего стандарта.

Использование исключительно идентификатора ТС нарушает требование о том. что ERI не будет легко использоваться для запуска атаки на ТС. Принятие попытки записи данных с применением исключительно идентификатора ТС в качестве информации аутентификации может быть использовано в качестве такого триггера. Применение PIN-кода снижает этот риск.

5.3.6 Идентификация ключа государственной сертификации

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

5.4 Описание архитектуры взаимосвязи

5.4.1 Идентификация транспортного средства с авторизованным считывателем короткого замыкания

На рисунке 5 представлена концепция взаимосвязи для идентификации ТС с авторизованным считывателем ERI с использованием коротких сообщений.

Поликяжгель:

Позиции:

Оборуйвмиик

Вашимамь:

Рисунок 5 — Взаимосвязь в ближней зоне с авторизованным считывателем

8 настоящем стандарте использован прикладной уровень беспроводного интерфейса между бортовым оборудованием ERI и внешними считывателями ERI с малой дальностью.

Прим вча н и е — Внешний интерфейс считывателя ERI ТС соответствует эталонной точке OELTA (см. приложение А с учетом (5]; 5.5.1). Внешний интерфейс считывателя ERI бэк-офиса соответствует эталонной точке ALPHA (см. [5]).

Описание интерфейса между внешним считывателем ERI и ВОЕ выходит за рамки настоящего стандарта. Это может использоваться, например, для ввода в эксплуатацию считывателя ERI. обмена белыми или черными списками и/или для загрузки результатов чтения, т. е. локальным интерфейсом в бэк-офисе или в широкополосном сетевом интерфейсе.

Бэк-офис может быть офисом регистрирующего органа или дополнительного поставщика услуг.

Аналогичная ситуация относится и к аналогичной фигуре для идентификации ТС с авторизованным внешним считывателем бесконтактного доступа.

5.4.2 Идентификация транспортного средства с помощью авторизованного считывателя с малой дальностью

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

Пользователь:

Позиция:

Овордаоиыик

вам имамы

Рисунок 6 — Коммуникации с малой дальностью связи с нвавторизоаанным считывателем

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

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

Аналогичная ситуация относится и к аналогичной фигуре для идентификации ТС с несанкционированным внешним считывателем бесконтактного доступа.

5.4.3 Общая концепция коммуникации для удаленного доступа

Настоящий стандарт также поддерживает удаленный доступ к ERT. Регистрирующий орган может, например, использовать удаленный доступ, если он будет реализован, для проверки или обновления данных о дополнительных ТС или данных безопасности, владелец ERT может применять удаленный доступ для проверки данных ERI или авторизации дополнительного поставщика услуг.

На рисунке 7 представлена концепция взаимосвязи для удаленного доступа к ERTTC.

В настоящем стандарте представлен уровень приложения сетевого интерфейса между бортовым оборудованием ERI и дистанционным внешним устройством чтения/записи ERI.

Примечание — Реализация возможностей удаленного доступа выходит за рамки настоящего стандарта.

5.4.3.1 Бортовая связь

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

Ншяоящмй

сяндцгг

Рисунок 8 — Встроенная архитектура

Прим еча ни© — При конкретной реализации определяется, должны ли ERT и устройство связи быть отдельными компонентами.

5.5 Интерфейсы

5.5.1 Ближний беспроводной интерфейс

Взаимосвязь между бортовым оборудованием ERI и внешним считывателем/записывающим устройством ER, на коротких расстояниях использует стек протоколов, приведенный на рисунке 9.

AVI {см. [6] плюс дополнительные услуги)

Уровень ERI (добавление служб безопасности ERI и управления ими)

Уровень приложения, например прикладном уровень DSRC или аналогичный уровень Нижние слои

Рисунок 9 — Стек протокола для ближнего беспроводного интерфейса

Примечание — Отношение между этими уровнями и опорныкы точками ВЕГА к ZETA приведено на рисунке 10 (см. приложение А {5]). (Ориентир ALPHA расположен между считывающим устройством ERI и ВОЕ бэк-офиса.)

ОаТА(БЕСГРО ВОДНОЙ ИНТН’ФЗФ Рисунок 10 — Расположение уровня ERI в эталонной архитектуре (см. (5])

5.5.2 Бесконтактный интерфейс с ERT

Взаимосвязь между ERT и бортовым или внешним считывателем/записью проксимити использует стек протоколов, приведенный на рисунке 11.

AVI (см. (6] плюс дополнительные услуги}

Уровень ERI (добавление служб безопасности ERI и управления ими) Уровень передачи Нижние спои

Рисунок 11 — Стек протокола для интерфейса между ERT и считывающим устройством

6 Требования к интерфейсу

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

В настоящем разделе представлен интерфейс прикладного уровня для доступа к данным ERI в ERT. в частности:

в 6.2 приведено абстрактное определение транзакций ERI с использованием ASN.1:

6.3.2 определен бесконтактный интерфейс с ERT;

6.3.3 определен ближайший беспроводной интерфейс между бортовым оборудованием ERI и внешним считывающим устройством/считывателем ERI;

6.3.4 приведен интерфейс для удаленного доступа.

Уровень приложения встроенного интерфейса определяется как реализация абстрактных определений в 6.2. Внешние интерфейсы, приведенные е 6.3.3 и 6.3.4. используются либо для прямой связи с ERT в том случае, когда встроенное оборудование ERI интегрировано в одно устройство (ERT). либо для передачи блоков данных протокола ERI на встроенный считыватель/эапись ERI (см. рисунок 1}.

6.2 Абстрактные определения транзакций

6.2.1 Описание транзакций

В настоящем пункте определены транзакции ERI в таблице 3.

Таблица 3 — Обязательные и необязательные транзакции

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

Определение транзакций основано на классе информационных объектов ASN.1 TRANSACTION (см. 6.2.2).

8 6.2.18 приведены определения, являющиеся общими для нескольких транзакций.

6.2.2 POU ERI и транзакции

6.2.2.1 Концепция транзакции

Запись и чтение данных в/из ERT достигается посредством транзакций, которые определены как экземпляры класса информационных объектов TRANSACTION.

Класс информационных объектов TRANSACTION определен следующим образом:

Одна транзакция не должна вызываться встроенным устройством чтения/записи ERT в то время, когда ERT выполняет другую транзакцию. Если ответ может быть непредсказуемым, то атомарность транзакций должна быть гарантирована.

Попе SArgumentType должно указывать тил данных аргумента транзакции.

Если транзакция выполнена успешно, она возвращает результат, указанный в поле &ResultType. В противном случае возвращается код ошибки, указанный в поле &ErrorCode.

Попе &ResultType должно указывать тип данных возвращаемого значения результата транзакции при успешной транзакции.

Попе &ErrorCode. если оно присутствует, имеет тип ErrorCode.

Поле &transactionCode указывает целочисленное значение, которое используется для идентификации типа транзакции.

в.2.2.2 Единицы данных протокола ERI

Блоки данных протокола ERI (PDU) определены следующим образом:

EriRequestPduSEQUENCE {

transactCode TRANSACTION.&transactionCode

(EriTransactions)),

argument TRANSACTION.&ArgumentType

{{EriTransactions} {©.transactCode}) OPTIONAL

}

EriResponsePdu ::= CHOICE { resultPdu EriResuttPdu. errorPdu EriErrorPdu }

EriResuttPduSEQUENCE {

transactCode TRANSACTION.&transactionCode

(EriTransactions)),

result TRANSACTION.&ResuNType (

{@ .transactCode})

}

EriErrorPduSEQUENCE (

transactCode TRANSACTION.&transacbonCode

{EriTransactions}),

error TRANSACTION.&ErrorCodes (

{©.transactCode})

}

EriTransactions

TRANSACTION ::= {

getEnData |

getAuthenticatedEriData |

selEriData | getCipriertextHtstoricEriData |

getCleartextHistoricEriData | getPubbcCertificateVerificationKeytd

| getPublicEndphermentKeyErt |

commissionErl | withdrawCommissxxiing |

getCiphertextHistoricComData | getCleartextHistoricComData |

updateAccessControiList |

getCiphertextAccessControlListEntry | getCleartextAccessControiListEntry

| getErtCapabdities }

Блок данных протокола ERI имеет тип EriData и является либо EriRequestPdu. либо EriResponse

Pdu.

Блок данных протокола EriRequestPdu используется для вызова транзакции, которая должна быть выполнена ERT.

Единица протокола данных EriResponsePdu используется для результата или уведомления об ошибке транзакции, выполняемой ERT.

EriTransactions задает набор транзакций ERI.

Компонент transactCode должен содержать значение кода транзакции для транзакции в установленных EriTransactions.

Компонент аргумента, при его наличии, должен быть того же типа, который указан для аргумента транзакции, идентифицируемой значением transactCode.

Компонент аргумента должен присутствовать, если аргумент для транзакции определен, и отсутствовать. если не определен.

Компонент результата должен быть того же типа, что и для результата транзакции, идентифицированного значением transactCode.

Компонент ошибки должен быть кодом ошибки из набора кодов ошибок, как указано для транзакции. идентифицированной значением transactCode.

6.2.3 Получить данные ERI

6.2.3.1 Операция получения данных ERI

Операция getEriData используется для чтения данных ERI с помощью считывателя ERI. Операция getEriData определена следующим образом:

Операция getEriData вызывается с аргументом GetEriDataArgument и возвращает результат GetEriDataResult.

Когда ERT еще не настроена, возвращается код ошибки noiCustomized.

Операция getEriData является единственной критически важной транзакцией ERI.

Примечание — Это единственная транзакция, которая должна быть выполнена во время движения ТС. Кроме того, отсутствует возможность предотвратить идентификацию посредством высокой скорости ТС.

6.2.3.2 Аргумент транзакции данных ERI

Тип GetEriDataArgument определен следующим образом:

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

Примечание — Компонент onBehalfOf идентифицирует либо регистрирующий орган, либо дополнительный поставщик услуг.

Компонент вызова — это случайное число, генерируемое считывателем ERI. которое в результате должно быть возвращено для того, чтобы показать, что возвращенный результат действительно является результатом этого вызова, а не реплицированного сообщения.

Компонент includeAdditionalData должен быть использован для того, чтобы указать, будет ли результат содержать дополнительные данные ТС. Если использован FALSE, то включен только идентификатор ТС; если TRUE, то также должны быть включены дополнительные данные ТС (при их наличии). предоставленные регистрирующим органом ТС.

в.2.3.3 Результат транзакции данных ERI

Тип GetEriDataResult определен следующим образом.

GetEriDataResuH ::= SEQUENCE { registrationAuthority

Компонент registrationAuthority. при его наличии, должен идентифицировать регистрирующий орган ТС.

Компонент registrationAuthority должен присутствовать, когда ERT вводится в эксплуатацию, и отсутствовать в обратном случае.

Компонент eriResultOata должен содержать защищенные данные ERI открытого текста (см. 6.2.18.1). Четкие данные ERI должны быть защищены, т. е. подписаны и/или зашифрованы, в соответствии

с возможностями ERT.

6.2.3.4 Данные Cleartext ERI

Тип CleartextEriData используется для данных ERI в соответствии с запросом на вызов транзакции getEriData или GetAuthenticatedEriOata и определяется следующим образом:

Компонент eriDataOrld имеет тип EriOataOrld. как определено ниже.

Компонент ertSecurityStatus. при его наличии, должен иметь тип ErtSecurityFiags. как определено

ниже.

Компонент ertSecurityStatus должен присутствовать, если ERT имеет возможность установить или сбросить как минимум один из битов состояния безопасности. В противном случае компонент не должен присутствовать.

6.2.3.5 Данные или идентификатор ERI

Тип EriDataOrld используется для указания данных Vehicleld или ERI и определяется следующим образом:

Альтернатива Vehideld должна использоваться, если компонент indudeAdditionalData в поле аргу* мента вызываемой транзакции имеет значение FALSE.

Компонент unsignedDatedEriDala должен использоваться, если компонент indudeAdditionalData в поле аргумента вызываемой транзакции имеет значение TRUE и данные ERI не подписаны при записи в ERT.

Значение компонента unsignedDatedEriDala является значением данных, полученных от ERI. как записано в ERT при выполнении последней транзакции данных ERI.

Компонент dateAndSignedEriData должен использоваться, если компонент indudeAdditionalData в поле аргумента вызываемой транзакции имеет значение TRUE и данные ERI подписаны при записи в ERT.

Значение компонента dateAndSignedEriData должно быть значением устаревших и подписанных данных ERI. записанных в ERT последней успешно выполненной транзакцией данных ERI.

6.2.3.6 Данные ERI

Тип EriData должен использоваться для данных ERI и определяется следующим образом:

Идентификатор должен содержать идентификатор ТС в соответствии с ПНСТ 343—2018. Дополнительным компонентом EriData является строка октета, содержащая дополнительные данные ERI согласно ПНСТ 343—2018.

Примечание —При переносе дополнительных данных ERI в строку октета ERT не нуждается в ходировз-нии/декодировании дополнительных данных ER1. Поэтому будущие изменения определения дополнительного типа данных ERI также не будут влиять на дизайн ERT (кроме максимального размера записи данных ERI).

6.2.3.7 Флаги безопасности ERT

Целью флагов безопасности ERT является сигнализация безопасности, которая может быть вызвана попытками вмешаться в ERT.

Примечание —Возможности обеспечения безопасности ERT можно получить с помощью транзакций получения возможностей ERT. Тип ErtSecurityFlags используется для указания флагов безопасности и определяется следующим образом:

ErtSecurityFlagsBIT STRING {

flagsHaveBeenResetted (0). notCommissioned (1).

lowSupptyVoitageirtdicabon (2). highSuppfyVoltagelndicabon

(3) .

towCtockFrequencylndication

(4) .

highCiockFrequencytndication

(5) .

towTemperaturetndicdtion (6). highTemperaturetndication (7)

} (SIZE (0..16)) - M 8 .. 15 reserved (or future use

Начальное значение битовой строки должно быть «0100000000000000» В. т. е. еще не введено в эксплуатацию, еще не обнаружено и сброс отсутствует.

Если значение типа ErtSecurityFlags равно 0000000000000000 8 или ’0100000000000000 В. операция сброса не изменит это значение. В противном случае операция сброса установит его на «1000000000000000».

Бит notCommiss*oned будет установлен е 1. если транзакция ввода в эксплуатацию будет вылол-йена успешно, и установлен в 0. если вызывается транзакция ввода/вывода.

Примечание — Значение компонента ErtSecurityFlags можно сбросить с помощью транзакции ERT комиссии.

Бит 2 .. 15 будет установлен в 1. если соответствующее условие обнаружено.

Примечание — Значение 0 указывает на то. что условие не обнаружено. Это может быть связано с тем. что ERT не имеет соответствующей возможности обнаружения (см. также 6.2.17).

6.2.4 Аутентифицированные данные ERI

6.2.4.1 Аутентифицированная транзакция данных ERI

Операция getAuthenticatedEriOata используется для получения аутентифицированной версии данных ERI и определяется следующим образом:

Операция getAuthenticatedEriOata вызывается с аргументом GetAuthenticatedEriDataArgument. Если ERT настроена, возвращается GetAuthenticatedEriDataResult.

Если ERT не настроена, возвращается код нестандартной ошибки.

6.2.4.2 Аутентифицированный аргумент транзакции данных ERI Тип GetAutbenPcatedEriDataArgument определен следующим образом.

GetAuthenticatedEriDataArgumenl ::= SEQUENCE { ertHokJerCredenbals ErtHolderCredentials. challenge Challenge.

indudeAdditionalData BOOLEAN )

Компонент ertHolderCredentials должен содержать учетные данные владельца ERT. т. е. идентификатор ТС и PIN-код владельца ERT.

Компонент вызова и компонент indudeAdditionalData определены так же. как и в типе GetEriDataArgument.

6.2.4.3 Результат аутентификации данных ERI

Тип GetAuthenPcatedEriDataResult определен следующим образом:

GetAuthenticatedEriDataResult ::= SEQUENCE {

registrationAutho Entityld OPTIONAL,

rity

authenlicateResul CLEAR-SECURED

(Data (CleartextEriData}

>

Компонент registrationAuthority. при его наличии, должен идентифицировать регистрирующий орган ТС.

Компонент registrationAuthority должен присутствовать, если ERT введен в эксплуатацию, и отсутствовать в противном случае.

Элемент authenticateResultData должен содержать защищенные, но не зашифрованные данные ERI открытого текста (см. 6.2.18.1}.

Четкие данные ERI четко защищены, т. е. подписаны/не подписаны, в соответствии с возможностями ERT.

6.2.5 Установка данных ERI

6.2.5.1 Установленная транзакция данных ERI

Операция setEriData используется для настройки и обновления ERT и определяется следующим образом:

setEriOata вызывается с аргументом типа SetEriDataArgument.

Если транзакция выполнена успешно. ERT возвращает значение NULL. В противном случае воз* вращается один из кодов ошибок из SetEriDataErrors.

Данные не должны храниться в ERT. если транзакция не выполнена успешно.

Когда транзакция выполняется в первый раз с помощью ERT. считается, что ERT настроена. Когда

ERT настроена. ТС в данной ERT не может быть изменено ни при каких обстоятельствах.

Прим еча нив — Если ERT не имеет возможности проверки подписи, любой писатель может записывать любые данные ERI в ERT.

6.2.5.2 Аргумент транзакции данных набора ERI

Тип SetEriDataArgument определен следующим образом:

SetEriDataArgument ::= CHOICE { dearTextArgument encryptedArgument }

Альтернатива зашифрованного аргумента не выбирается, если у ERT отсутствуют возможности дешифрования.

Примечание — Независимо от того, может ли ERT определить возможности дешифрования с помощью транзакции получения ERT.

Если выбрана альтернатива encryptment. значение ClearTextSetEnDataArgument должно быть за* шифровано с помощью ключа общедоступного шифрования, который может быть получен с транзакцией getPublicEnciphermentKeyErt.

6.2.5.3 Тип аргумента данных типа ERI

Тип ClearTextSetEnDataArgument определен следующим образом:

ClearTextSelEriDataArgument ::= CHOICE {

authenUcatedEriData BOE-AUTHENTICATED (DATED (EriData}}.

notAuthenticatedEriData DATED {EriData}

}

Аутентифицированная альтернатива EriData выбирается автором ERI в тот момент, когда ERT имеет возможности проверки подписи, и может быть выбрана, когда ERT не имеет возможностей проверки подписи. NotAuthenticatedEriData может быть выбрана только в том случае, если ERT не имеет возможностей проверки подписи.

Прим еча н и е — Независимо от того, может ли ERT иметь возможности проверки подписи, можно определить транзакцию get ERT.

ЛИСТ 344—2018

Аутентифицированные EriData, при их наличии, должны содержать данные ERI как датированные и подписанные [см. перечисление а) 6.2.18.3] регистрирующим органом или изготовителем, включая сертификат(ы) для открытого ключа проверки регистрирующего органа или производителя.

NotAuthenticatedEriData. при его наличии, должен содержать данные ERI. устаревшие [см. перечисление а) 6.2.18.3].

Когда транзакция вызывается в течение второго или последующего времени. ТС в аргументе должно быть таким же. как и при настройке ERT.

б. 2.5.4 Регистрация заданных аргументов данных ERI

Значение CiearTextSetEriDataArgument каждой транзакции setEriData должно быть последовательно пронумеровано и сохранено в ERT для последующего извлечения. Значение ClearText SetEriOataArgument транзакции настройки должно быть пронумеровано 1.

ERT должна иметь возможность сохранять одно или несколько значений ClearTextSetEriDataArgu-merit, т. е. ноль значений или более от успешно выполненных ранее установленных вызовов данных ERI.

Если достигнуто максимальное количество значений CiearTextSetEriDataArgument, которые удалось сохранить ERT, применяется следующая процедура:

когда ERT может хранить только одно значение CiearTextSetEriDataArgument, т. е. исторические данные не хранятся, новое значение CiearTextSetEriDataArgument заменяет старое;

когда ERT может хранить два значения CiearTextSetEriDataArgument или более, т. е. хранить исторические данные, новое значение CiearTextSetEriDataArgument заменяет второе старое существующее значение CiearTextSetEriDataArgument.

Примечание — Удаляя второе старое, а не самое старое значение, исходные данные ERI сохраняются.

Если размер значения CiearTextSetEriDataArgument превышает максимальное значение, разрешенное для этого аргумента, возвращается код ошибки resourceLimitExceeded и обновление данных ERI не происходит.

в. 2.5.5 Аутентификация данных ERI

Данные аутентификации не должны иметь компонент даты с датой, предшествующей дате предыдущего вызова setEriData.

Примечание — Это также защита от повторной атаки, предотвращающая незаконную переустановку исторической версии данных ERI несанкционированной записи ERI.

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

Если транзакция вызывается при вводе ERT. объект Entityld в данных аутентификации должен быть таким же. как и в транзакции ввода в эксплуатацию (т. е. от того же регистрирующего органа).

Сделка не должна вызываться во время снятия ввода в эксплуатацию.

Когда у ERT есть возможности проверки подписи, применяются следующие условия:

- если ERT не вводилась в эксплуатацию, данные в аргументе подписываются изготовителем или регистрирующим органом;

- если ERT была введена в эксплуатацию как минимум один раз, данные в аргументе должны быть подписаны регистрирующим органом:

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

в.2.5.6 Установленные ошибки транзакции данных ERI

Тип SetEriDataErrors является подтипом типа ErrorCode. который определен следующим образом:

SetEriDataErrors имеют тип EriErrorCode и содержат перечисленные значения.

Когда ERT имеет возможности проверки подписи и данные ERI в аргументе не аутентифицированы, возвращается значение незаконного аргумента.

Когда транзакция вызывается во время снятия ввода в эксплуатацию, возвращается значение notCommissioned.

6.2.6 Получать исторические данные ERI зашифрованного текста

6.2.6.1 Передача данных об аутентификации ERI зашифрованного текста

Операция getCiphertextH istoricEriData используется для извлечения окончательно зашифрованно

го аргумента предыдущей транзакции setEriData и определяется следующим образом:

Операция getCiphertextHistoricEriData вызывается с аргументом GetCiphertextHistoricEriDataArgu-

ment.

Если ERT настроена, транзакция возвращает исторические данные ERI. подписанные и/или зашифрованные в соответствии с возможностями ERT (см. 6.2.18.1 для определения SECURED 0).

Если ERT еще не настроена, возвращается код с нестандартной ошибкой.

6.2.6.2 Аргумент транзакции данных ERI получения зашифрованного текста Тип GetCiphertextHistoricEriDataArgument определен следующим образом:

GetCiphertextHistoricEriDataArgument ::= SEQUENCE ( onBehalfOf Entityld OPTIONAL,

challenge Challenge,

number INTEGER (1..int4)

)

Компонент onBehalfOf. при его наличии, указывает объект, открытый ключ шифрования которого в конечном итоге будет использован для возвращаемых данных. Если это не указано, значением по умолчанию является объект Entityld регистрирующего органа ТС. Когда ERT еще не введена в эксплуатацию, значение компонента onBehalfOf игнорируется.

Компонент вызова — это случайное число, генерируемое считывателем ERI. которое в конечном итоге должно быть возвращено в подписанной части результата, для того чтобы показать, что возвращенный результат является результатом этого вызова, а не реплицированного сообщения.

Сохраненные аргументы транзакций setEriData последовательно нумеруются. Первый сохраненный аргумент (для настройки транзакции setEriData) пронумерован 1.

Компонент number идентифицирует аргумент вызова setEriData.

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

Когда значение числового компонента более числа последнего сохраненного аргумента, данные этого последнего аргумента должны быть возвращены.

6.2.6.3 Исторические данные ERI

Тип HistoricEnData используется для извлечения аргументов и для установки транзакций данных ERI и определяется следующим образом:

Компонент числа HistoricEriData идентифицирует значение ClearTextSetEriDataArgument. переданное в компоненте HistoricalRecord.

Компонент outOf указывает число самого последнего сохраненного значения ClearText SetEriDataArgument.

Компонент historyRecord содержит значение ClearTextSetEriDataArgument. определенное значением числового компонента.

6.2.7 Получение исторических данных ERI с открытым текстом

6.2.7.1 Исходная транзакция данных ERI

Операция getCleartextHistoricEriData должна использоваться для извлечения аргумента предыдущих транзакций setEriData в открытом тексте и определяется следующим образом:

Поле ARGUMENT имеет тип GetCleartextHistoricEriDataArgument.

Транзакция возвращает исторические данные ERI (см. 6.2.6.3), подписанные/неподписанные в соответствии с возможностями ERT (см. 6.2.18.1 при определении CLEAR-SECURED 0).

Если ERT еще не настроена, возвращается код с нестандартной ошибкой.

6.2.7.2 Исходный аргумент транзакции данных ERI

Тип GetCleartextHistoricEriDataArgument определен следующим образом:

GetCleartextHistoricEriOataArgument ::= SEQUENCE ( credentials ErtHolderCredentials.

challenge Challenge,

number INTEGER (1..int4)

}

Компонент учетных данных определяется так же. как и в аргументе транзакции getAuthenticated EriData.

Компоненты вызова и числа определяются так же, как и в аргументе транзакции getCiphertextHistoricEriData.

6.2.8 Получение транзакции с идентификатором ключа проверки подлинности сертификата

Операция getPublicCertificateVerificationKeyld используется для извлечения идентификатора открытого ключа проверки, который будет использоваться для проверки сертификатов открытого ключа высшего уровня. Операция getPublicCertificateVerificationKeytd определяется следующим образом:

getPubbcCertiflcateVerificationKeytd TRANSACTION ::={ ARGUMENT NULL RESULT Keytd CODE 6

>

Поле аргумента имеет тип NULL.

Результатом транзакции является идентификатор открытого ключа проверки, который будет использоваться для проверки сертификатов открытого ключа toptevel. Если ERT не поддерживает проверку подписи или этот ключ недоступен, возвращаемое значение равно нулю.

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

6.2.9 Получение общедоступного ключа шифрования ERT

6.2.9.1 Получение транзакции общедоступного ключа шифрования ERT

Транзакция getPublicEnciphermentKeyErt должна использоваться для извлечения ключа общедоступного шифрования ERT регистрирующим органом. Этот ключ необходим для шифрования данных личного ввода в эксплуатацию. Операция getPublicEnciphermentKeyErt определена следующим образом:

Поле аргумента имеет тип BOE-AUTHENTICATED {Vehicleld} и содержит идентификатор Vehicleld как аутентифицированное 8ОЕ (см. 6.2.18.4). Подписчиком данных аутентификации является регистрирующий орган.

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

В случае успеха транзакция возвращает общедоступный ключ шифрования для ERT. Если это не удается, транзакция возвращает значение GetPublicEnciphermentKeyErrors.

6.2.9.2 Получение ошибок публичного шифрования транзакций ERT

Тип GetPublicEnciphermentKeyErrors — это подтип типа ErrorCode. который определяется следу* ющим образом:

GetPublicEnciphermentKeyErrors ErrorCode ::= { illegalArgument )

illegalVehideld )

iiegaiCertificate |

rtlegelSignature | ittegalEntity | noOeciphermentCapabilrty |

olherError }

Тип GetPublicEnciphermentKeyErrors имеет тип EriErrorCode и должен принимать одно из перечисленных значений.

6.2.10 Комиссия ERT

6.2.10.1 Комиссия по сделке ERT

Регистрирующий орган должен использовать транзакцию commErt для поручения ERT или обновления параметров безопасности ERT. Сделка commissionErt определена следующим образом:

Примечание — Сделка ввода в эксплуатацию может быть вызвана только при настройке ERT, Аргумент comissionErt транзакции имеет тип CommissionErtArgument.

Если транзакция выполнена успешно. ERT возвращает значение NULL. В противном случае воз* вращается один из кодов ошибок CommissionErtErrors.

Данные не должны храниться в ERT. если транзакция не выполнена успешно.

Примечание — Если ERT не имеет возможности проводки подписи, любой автор мажет записать в ERT данные ввода е эксплуатацию.

6.2.10.2 Аргумент ввода в эксплуатацию ERT

Тип CommissionErtArgument определен следующим образом:

CommisstonErtArgument ::= CHOICE { authenticaledData notAulhenticatedData )

Альтернатива аутентифицированной альтернативы выбирается, когда ERT имеет возможность проверки подписи, и может быть выбрана, когда ERT не имеет возможностей проверки подписи. NotAuthenticatedData может быть выбрана только в том случае, если ERT не имеет возможности про* верки подписи.

Аутентифицированные данные, при их наличии, должны содержать данные о вводе в эксплуатацию. как датированные и подписанные [см. перечисление а) 6.2.18.3 и 6.2.18.3] регистрирующим органом. включая сертификат(ы) для открытого ключа проверки регистрирующего органа.

Неаутентифицированные данные, при их наличии, должны содержать данные о вводе в эксплуатацию [см. перечисление а) 6.2.18.3) регистрирующим органом.

6.2.10.3 Регистрация ввода в эксплуатацию ERT и снятия аргументов ввода в эксплуатацию

Аргументы комиссии ERT и снятия транзакций ввода в эксплуатацию, которые выполняются

успешно, должны быть последовательно пронумерованы и сохранены для последующего поиска. Аргумент первого успешного вызова должен быть пронумерован 1.

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

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

если ERT может хранить только один аргумент, т. е. исторические данные не хранятся, новый аргумент заменяет старый;

если ERT может хранить два аргумента или более, т. е. хранить исторические данные, новый аргумент заменяет второй самый старый аргумент.

Если размер аргумента превышает максимальный размер, который может хранить ERT. возвращается код ошибки resourceLimitExceeded.

6.2.10.4 Данные для ввода в эксплуатацию

Тип ввода в эксплуатацию содержит все данные, необходимые для ввода в эксплуатацию ERT. и определяется следующим образом:

CommtssioningData ::= SEQUENCE { vehicleld Vehicleld.

registrabonAuthority Entrtyld. resetSecurityFlags BOOLEAN. enciphermentKeyld Keytd OPTIONAL. pubbcEnciphermentKeyAuthority PublicEnaphermentKey OPTIONAL. pubbcVerificalionKeyCertificete ErtCertficate OPTIONAL. privateData ENCRYPTED {PnvateCommissioningData} OPTIONAL }

Компонент vehideld идентифицирует ТС. Значение должно быть таким же. как и для настройки

ERT.

Компонент registrationAuthority идентифицирует регистрирующий орган, который (повторно) поручил ERT.

8 компоненте resetSecurityFlags указывается, следует ли сбросить флаги безопасности: если TRUE, они должны быть сброшены: если FALSE, они не будут сброшены.

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

Примечание — При возврате с зашифрованными данными это значение может использоваться для определения соответствующего частного ключа дешифрования.

Компонент enciphermentKeyld должен присутствовать, если присутствует компонент publicEnciphermentKeyAuthority. В противном случае компонент должен отсутствовать.

Компонент publicEndphermentKeyAuthority, при его наличии, содержит открытый ключ шифрования регистрирующего органа, указанный компонентом registrationAuthority. Данный ключ используется для шифрования результатов, возвращаемых ERT. если это применимо.

Компонент publicEnciphermentKeyAuthority должен присутствовать, когда ERT имеет возможности шифрования, которые должны быть включены. В противном случае компонент должен отсутствовать, и любые возможности шифрования ERT. при их наличии, должны быть отключены.

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

Компонент publicVerificationKeyCertificate. при его наличии, должен содержать сертификат для общедоступного ключа проверки для проверки подписей ERT. Этот сертификат выдается регистрирующим органом, указанным в компоненте registrationAuthority.

Компонент pubticVenficationKeyCertificate должен присутствовать. если компонент privateSignatureKeyErt присутствует в компоненте privateData. В противном случае он отсутствует.

Компонент privateData. при его наличии, содержит зашифрованные PrivateCommissioningData. Используемый общедоступный ключ шифрования должен быть PublicEnciphermentKey. который может быть получен с помощью транзакции getPublicEnciphermentKeyErt.

Компонент privateData должен присутствовать, если тип PrivateCommissioningData содержит как минимум один компонент. 8 противном случае он отсутствует.

6.2.10.5 Данные личного ввода в эксплуатацию

Тип PrivateCommissioningData содержит все личные данные, необходимые для ввода в эксплуатацию ERT, и определяется следующим образом:

PrivateCommissioningData ::= SEQUENCE (

privateSignatureKeyErt PnvateSignatureKey OPTIONAL, pin PIN OPTIONAL }

Компонент privateSignatureKeyErt. при его наличии, содержит ключ частной подписи, который будет использоваться ERT для подписи результата транзакций.

Компонент privateSignatureKeyErt должен присутствовать, когда ERT имеет возможности подписывания. которые должны быть включены. В противном случае компонент должен отсутствовать, и любые возможности подписки, при их наличии, должны быть отключены.

Примечание — Идентификатор ключа не требуется. ERT всегда прикрепляет сертификат для соответствующего открытого ключа проверки к каждой подписи ERT.

Контактный компонент, при его наличии, должен содержать случайный PIN-код. который может использоваться в сочетании с ТС. для того чтобы получить доступ к данным ERI с открытым текстом (например, держателем ERT).

Примечание — Безопасное распространение PIN-кода на держатель ERT выходит за рамки настоящего стандарта.

Компонент штыря должен присутствовать, если возможности шифрования ERT включены и должны поддерживаться getAuthenticatedEnData. getCteartextHistoricEriData. UpdateAccesControlList (для держателей) или getCleartextAccessControlListEntry. В противном случае он должен отсутствовать.

Если контактный компонент присутствует, когда возможности шифрования ERT отключены, его значение игнорируется.

6.2.10.6 Ошибки транзакции комиссии ERT

Тип CommissionErtErrors определен следующим образом:

CommissionErtErrors ErrorCode ::= {

iltegalArgument |

iltegalVehicleld |

illegalCertificate |

illegalSignature | iltegalEntity

iltegalDate | notCustomized |

resourceLimitExceeded |

noEncipherrrwntCapabilrty |

secretKeyEncryptionAlgorithmNotSuppor

I

pubfccKeyEncryptionAlgonthmNotSuppor

I

noSigningCapebility |

hashmgAlgorithmNotSupported | signingAlgorithmNotSupported |

otherError }

Тип CommissionErtErrors имеет тип ErrorCode и должен принимать одно из перечисленных значений.

6.2.11 ввод в эксплуатацию

6.2.11.1 Операция снятия взыскания

Операция снятия с производства должна быть использована для снятия ввода в эксплуатацию ERT. например, в случае окончания срока службы ТС.

Операция снятия с производства определена следующим образом:

wilhdrawCommissioning TRANSACTION ::= (

- this transaction also removes all public encipherment keys

WilhdrawCommissioning Argument

SECURED {WithdrawCommissioningResiitData}

{WithdrawCommissioningErrors}

wrthdrawCommissioningCode

}

withdrawCommissioningCode INTEGER ::= 9

Поле ARGUMENT должно иметь тип WithdrawCommissioningArgument.

Если ERT введена в эксплуатацию, транзакция возвращает SECUREO WithdrawCommissroning-ResultData (см. ниже), подписанный и/или зашифрованный в соответствии с возможностями ERT (см.

6.2.18.1 для определения SECURED 0). 8 противном случае возвращается один из кодов ошибок из CommissionErtErrors.

Регистрирующий орган, который заказал ERT. может быть вызван транзакцией.

Выполнение этой транзакции приведет:

к удалению всех ключей и PIN-кода. при их наличии, установленных регистрирующим органом посредством транзакции ввода в эксплуатацию:

удалению всех записей из списка управления доступом:

отключению, в случае применения, возможностей шифрования ERT; установке битов «notCommissioned» в флагах безопасности ERT; нумерации и сохранению значения аргумента (см. 6.2.10.3).

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

6.2.11.2 Аргумент транзакции снятия вводом

Тип WithdrawCommissioningArgurnent определен следующим образом:

WithdrawCommissioningArgufnent ;:= CHOICE { authenticatedData BOE-AUTHENTICATED

NotAuthenticatedData Vehicleld

}

Альтернатива authenticatedData выбирается в том случае, когда ERT имеет возможности проверки подписи, и может быть выбрана тогда, когда ERT не имеет данных возможностей. NotAuthenticatedData может быть выбран только при условии отсутствия у ERT возможности проверки подписи.

Аутентифицированные данные, при их наличии, должны содержать идентификатор ТС, подписанный (см. 6.2.18.4) регистрирующим органом, включая сертификаты) для открытого ключа проверки регистрирующего органа.

Неаутентифицированные данные, при их наличии, должны содержать идентификатор ТС.

Прим еча нив — Если ERT не имеет возможности проверки подписи, каждый мажет снять ввод в эксплуатацию. даже если выбрана альтернатива authenticatedData (если подпись не подтверждена, можно использовать фиктивную подпись).

6.2.11.3 Данные результата транзакции снятия вводом

Тип WithdrawCommissroningResultData определен следующим образом:

WrthdrawCommissiooingResuitData wrthdrawCommissioningCode) SEQUENCE {

withdrawn WithdrawCommissioningArgument.

historicComData HistoricComData }

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

Компонент HistoricalComData должен содержать значение самого последнего хранимого аргумен

та транзакции ERT для ввода в эксплуатацию.

6.2.11.4 Ошибки транзакции снятия с производства

Тип WithdrawCommissioningErrors определен следующим образом:

WithdrawCommissioningErrors ErrorCode ::= { lilegalArgumenti |

OegalVehicleld |

rilegalCertiftcate |

rilegalSignature | iilegalEntity

| lllegaiDate |

notCustomized | notCommissioned | otherError }

Тип WithdrawCommissioningErrors имеет тип EriErrorCode и должен принимать одно из перечисленных значений.

6.2.12 Получение данных ввода в зашифрованный текст

6.2.12.1 Получение транзакции с данными об аутентификации зашифрованного текста Операция getCiphertextHistoricComData используется для извлечения окончательно зашифрован

ного аргумента предыдущей транзакции CommissionErt и определяется следующим образом:

Поле ARGUMENT должно быть типа GetCiphertextHistoricComDataArgument.

При наличии ERT или ее вводе в эксплуатацию транзакция возвращает исторические данные

ввода в эксплуатацию, подписанные и/или зашифрованные в соответствии с возможностями ERT (см. 6.2.18.1 для определения SECURED 0).

Если ERT не введена в эксплуатацию, должен быть возвращен кодошибки notCommissioned.

6.2.12.2 Аргумент транзакции данных ввода данных зашифрованного текста Тип GetCiphertextHistoricEriDataArgument определен следующим образом:

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

Компонент вызова — это случайное число, генерируемое считывателем ERI. которое в конечном итоге должно быть возвращено в подписанной части результата, для того чтобы показать, что возвращенный результат является результатом этого вызова, а не реплицированного сообщения.

Сохраненные аргументы транзакций CommissionErt последовательно нумеруются. Первый сохраненный аргумент пронумерован 1.

Компонент number идентифицирует аргумент вызова CommissionErt.

Когда значением числового компонента является число удаленных аргументов, возвращается самый старый доступный аргумент успешно вызванной транзакции CommissionErt.

Когда значение числового компонента более числа последнего сохраненного аргумента, данные этого последнего аргумента должны быть возвращены.

6.2.12.3 Исторические данные ввода в эксплуатацию

Тип HistoricComData используется для исторических данных ввода в эксплуатацию и определяется следующим образом:

36