V2X расшифровывается как Vehicle-to-Everything. Это когда ваш автомобиль общается с окружающим миром, минуя вас.
Есть множество статей о том, что такое V2X и зачем это нужно. Есть описания работы системы разной степени подробности и достоверности, описания стандартов, кликбейтные новости, обзоры и т. д. А я бы хотел рассказать про европейскую систему безопасности Кооперативной Интеллектуальной Транспортной Системы (C-ITS). Из чего состоит, как работает, зачем нужна…
Так получилось, что уже более 10 лет я занимаюсь разработкой европейских стандартов кооперативных интеллектуальных транспортный систем (C-ITS) или, как их ещё называют, V2X в Европейском Институте Стандартизации Телекоммуникаций (ETSI). Тут и ITS G5 – европейская адаптация IEEE 802.11p, и GeoNetworking и разные приложения, типа САМ, DENM и др, и тестовые спецификации. Кому интересно – информации масса.
На этой картинке, которая кочует из статьи в статью, видны все эти уровни и связи между ними. Но справа есть один блок, который пересекает всю эту стройную картинку сверху вниз – система безопасности. Вот о ней то и поговорим.
Что это и зачем это надо
В обычной жизни в интернете (да, мы про нас, гиков) мы пользуемся системой безопасности, основанной на сертификатах X.509, которые нам рассылают сайты, чтоб подтвердить, что они те, за кого себя выдают.
В архитектуре C-ITS система безопасности делает ровно то же самое: позволяет получателю удостовериться, что отправитель сообщения имел право его отправлять. Но зачем придумывать новый велосипед? Чем плох старый? Да и нужно ли вообще всё это?
Ну начнем с того, зачем это нужно. Простой пример: автомобиль рассылает сообщения, содержащие параметры этого самого автомобиля: тип, положение, скорость и тд. Без системы безопасности ничего не мешает автомобилю повысить свой статус на дороге, например обозначить себя автомобилем специальных служб. А что будет, если какой-нибудь несознательный товарищ начнет слать сообщения о фейковых автомобилях на дороге или о неправильных сигналах светофора? Да ничего хорошего не будет. Значит система безопасности должна запрещать пользователю делать то, что ему не позволено.
Далее, автомобиль специальных служб Германии не имеет приоритета во Франции. И наоборот. Значит система безопасности должна ограничивать пользователя территориально.
Проданный полицейский автомобиль уже не торт, правильно? Добавляем ограничения по времени.
Более подробно все эти требования изложены и сведены в систему в документе ETSI TR 102 893 “Threat, Vulnerability and Risk Analysis (TVRA)”. Кому интересно – гуглим по номеру и читаем.
Как все это реализовать? Ответ есть: инфраструктура открытых ключей, иначе говоря, Public Key Infrastructure – PKI.
Вкратце, PKI представляет из себя иерархию сертификатов, каждый из которых имеет публичный ключ, какие-то поля, и подписан вышестоящим сертификатом. Поля вносят семантическую информацию, ключ и подпись нужны для валидации. Любой, кто имеет доступ к сертификату, может проверить целостность и подтвердить источник информации, подписанной этим сертификатом (точнее приватным ключом, соответствующим этому сертификату, но опустим для простоты).
И, как я уже говорил, такой велосипед давно изобретен: сертификаты X.509, которые широко используются повсюду в мире, имеют широкую поддержку, массу удостоверяющих центров с соответствующим оборудованием и т. д. Но нет, мы идем другим путём…
И основная причина тому - размер. Сертификат X.509 – довольно монструозная конструкция. И если при интернет-соединениях лишние 500 байт нас вообще не волнуют, то в ITS G5 максимальная длина пакета (MTU) ограничена 1492 байтами и никакой фрагментации не предусмотрено. И вот в эту корзинку надо положить и полезную информацию, и сертификат с ключами, и подпись.
К тому же автомобили и объекты инфраструктуры рассылают сообщения минимум раз в секунду, а обычно ещё чаще. И весь этот поток от всех окружающих автомобилей должен поместиться в канал шириной 20 МГц. В общем, борьба за размер имеет смысл.
И именно для минимизации размера в IEEE придумали стандарт IEEE 1609.2. В нём описаны форматы защищенных сообщений и сертификатов, перечислены криптографические алгоритмы, используемые для проверки подписи и кодирования информации. На сегодняшний момент в качестве алгоритмов используется криптография на эллиптических кривых (ECDSA и ECIES). Поддерживаются американские, европейские и китайские алгоритмы. Поддержка российских алгоритмов (пока неизвестных) планировалась, но…
Сертификаты IEEE 1609.2 имеют ограничения по времени, местоположению и разрешенным сервисам. Причем ограничения сертификатов удостоверяющих центров (CA) должны включать в себя ограничения сертификатов оконечных устройств.
Давайте теперь разберемся, как это всё работает, на простом примере:
Автомобиль дорожных служб, проводящий уборку снега в Москве, рассылает сообщения CАМ с информацией о себе и сообщения DENM о своей работе. Он должен иметь сертификат, позволяющий ему рассылать сейчас в Москве САМ от имени дорожных служб и DENM об уборке снега. Другие автомобили, получившие эти сообщения, проверяют, что выполняются ограничения по времени и местоположению, что сообщения разрешены сертификатом, которым они подписаны, что сам этот сертификат валиден относительно родительского сертификата, подписавшего его, что родительский сертификат валиден относительно своего родительского сертификата, и так, по цепочке, до самого верха, вплоть до корневого сертификата, который считается валидным по умолчанию. Уф… проверили? Можно предупредить водителя, что тут наконец-то снег убирают.
Такая же примерно история с сообщениями от светофоров, с запросами приоритетного проезда, с информацией о знаках и разных табло и так далее. Про стандарты прикладного уровня вообще можно написать целую серию статей.
Ну сертификаты... А где их взять?
А ничего нового – у удостоверяющих центров.
Работает это как-то так: Автомобиль создает ключевые пары и запрашивает сертификат у удостоверяющего центра, посылая ему свои свеженькие публичные ключи. Тот генерирует, подписывает и высылает сертификат. Всё, профит? А не очень. Вспомним о приватности. УЦ, каким бы защищённым он ни был, может теоретически «потерять» базу выданных сертификатов. Получается, что теоретически можно отследить перемещение автомобиля просто анализируя его сообщения. С этим надо что-то делать.
Дисклеймер:
Я понимаю, что отследить передвижения автомобиля, рассылающего информацию о своем перемещении, можно без всякого труда, вне зависимости от того, какие сертификаты он использует, пусть хоть меняет их каждую секунду. Но "считается", что это помогает на больших дистанциях, когда за автомобилем не следует "группа слежения".
Надо – сделали.
Процесс получения сертификатов разделили на 2 стадии – регистрация и авторизация, enrolment и authorization. И, соответственно, удостоверяющие центры также разделились на 2 категории – Enrolment Authority (EA) и Authorization Authority (AA).
Вся эта процедура описана в стандартах ETSI TS 102 940 и ETSI TS 102 941 и показана на картинке.
Итак, вкратце это работает так: при производстве автомобиль получает идентификатор (canonical ID) и начальный сертификат (Bootstrap certificate). Эта информация известна EA. Далее, автомобиль запрашивает и получает сертификат длительного действия (EC), который затем используется для получения псевдонима (AT) у AA. При этом AA запрашивает у EA разрешение на выдачу сертификата. И вот этот-то сертификат AT, вернее набор таких сертификатов, которые автомобиль постоянно меняет, и используется для подписи рассылаемых сообщений.
Все устроено так, что EA обладает информацией об автомобиле, но не знает какие сертификаты были ему выданы, а АА знает о сертификатах, но не знает кому именно он их выдал. Вот такая вот полу-анонимность.
А теперь допустим на секунду, что УЦ скомпрометирован. Сейф взломан, ключи утекли в народ. Что надо делать? Отзывать выданные сертификаты. Для этого корневой центр регулярно выпускает CRL – Certificate Revocation List, куда помещаются идентификаторы отозванных сертификатов удостоверяющих центров, а все выданные ими сертификаты считаются отозванными по цепочке доверия. Сертификаты оконечных устройств не добавляются в CRL, просто EA не будет выдавать всяким редискам новые сертификаты, а старые умрут сами собой.
Всё это красиво и хорошо работает в идеальном мире с одной единственной иерархией. Но оказывается, что мир не идеален, в нем много стран, и каждая хочет странного. А именно каждая страна хочет иметь собственный корневой удостоверяющий центр и управлять им как захочет. В результате пришлось добавлять сверху еще один уровень: Trust List Manager (TLM).
TLM выпускает так называемый Certificate Trust List (CTL), который содержит список корневых сертификатов, которые считаются доверенными. Остальные само-подписанные сертификаты не должны считаться таковыми.
Вот теперь всё. Теперь картинка полная. Но только на сегодняшний день.
Опыт различных пилотных проектов показывает, что есть у всей этой архитектуры некоторые подводные камни. А именно:
Получить AT на ходу через ретранслирующий узел практически невозможно. Просто не успевает дойти за время, пока автомобиль проезжает мимо. Приходится пользоваться сотовой связью или... стоять на месте.
Хорошо бы запрашивать AT сразу пакетом, а не лезть за каждым сертификатом отдельно. При этом чтобы невозможно было связать между собой разные AT.
Хорошо бы иметь возможность докладывать куда-нибудь о всяких редисках, чтобы им сертификаты не выдавали.
И т. д.
Для решения этих и других проблем ETSI сейчас работает над пакетом стандартов C-ITS Security Release 2, включающим в себя новые версии PKI инфраструктуры, пакетный режим получения сертификатов, сообщения об ошибочном поведении других субъектов C-ITS и другие изменения. Не переключайтесь…
Ну и кто хочет поэкспериментировать – welcome на https://github.com/fillabs/fsmsggen
