Mercedes: Сертификаты — что это?
Итак, сертификаты для диагностики автомобилей, что это такое и с чем это едят…
Современные технологии требуют повышенной защиты, таким образом предыдущее поколение блоков управления, использующих так называемую технологию «Seed — Key» для разграничения доступа, уже не могут обеспечить должный уровень безопасности. Поэтому немцы сильно много думали — что же со всем этим делать? И, наконец, придумали! Принцип тот же: запрос — ответ. Но вместо простой формулы подсчета числа теперь используется цифровая подпись!
Итак, как это работает:
Открываем сессию с блоком. Блок нам говорит:
— Привет! Ты кто?
— Я — диагност! Хочу тебе прошивку поменять!
— А у тебя права есть?
— Да! Вот мне сертификат выдал Mercedes!
— Покаж?!
— На, смотри!
— Хмм. да, точно, действующий сертификат. А он точно тебе принадлежит? Или ты его спер у кого?
— Ну неее, точно мой, Я владелец!
— А доказать «ProofOfOwnership» сможешь? Вот тебе последовательность байт от меня. Подпиши приватным ключем своего сертификата, что ты мне давал?
— Хорошо, вот подписал, на держи!
— Да, действительно, проверку прошел. Доступ к программированию открыт! Welcome
Так вот, сертификаты имеют разное назначение и делятся на два типа:
Aftersales — Для дилеров, автомастерских для послепродажного обслуживания автомобилей.
Developer — Для инженеров разработчиков, тестеров и прочих подразделений включая заводы производителей.
AfterSales сертификаты бывают:
AS-Standard — диагностика, активации, стирать ошибки…
AS-Enhanced — Обновление ПО, работа с литиевыми батареями
К сертификатам Aftersales также могут быть выпущены расширения (Extentions), расширяющие стандартные права. Например, есть у мастера сертификат Enhanced, но полетела батарея на EQS и нужно ее сбросить. А прав не хватает. Пишет мастер запрос в Mercedes. Ему одобряют и через некоторое время с сервера прилетает Extension с нужными правами.
Developer Enhanced — дает доступ к кодированию
И вообще, как работает кодирование?
Отправляем блоку кодировку, подписанную соответствующим сертификатом. Блок проверяет цифровую подпись и либо сохраняет кодировку, либо отклоняет запрос.
Раньше была контрольная сумма в конце кодировок, а сейчас цифровая подпись!
Когда Xentry запрашивает SCN кодирование, то сервер присылает кодировку, уже подписанную!
Теперь поговорим о времени. Это очень важная часть!
Итак, у каждого сертификата, как у любого документа есть дата выпуска и дата окончания его действия.
Так вот блок должен уметь проверять, просрочен предоставляемый ему сертификат или нет?
Для этого в каждом блоке предусмотрен часовой механизм. Который «тикает» только вперед. Как только подал питание на блок, так «часики пошли». Как только происходит коннект с блоком, то программа DTS или Xentry отправляет текущее время ПК в блок, и тот в свою очередь пытается синхронизировать свои внутренние часы.
Параметр, который отвечает за время в блоке называется «GeneralizedTime» и хранится он в формате YYYYMMDDTTMMSSZ например: 20230101235930Z
Частая проблема бывает, когда время на ПК диагноста по какой-то причине стоит неверное, например на 5 лет вперед )) Тогда в блок записывается неправильное время из будущего. И потом при попытке соединения мы предьявляем сертификат, который по мнению блока — просрочен! И нет никакой возможности сделать диагностику.
Для решения такой проблемы был сделан сертификат Time. Который дает права на «откат» времени назад до текущего времени
Итак, подведем итоги:
Standard — для диагностики (выдается на 6 месяцев)
Enhanced — для обновления софта (выдается на 14 дней)
Developer Enhanced или Coding — для кодирования (выдается на 14 дней)
Time — для обратной коррекции времени (выдается на 1 день)
Так как сертификат — это вещь очень секретная, то и хранить его нужно так чтобы никто его не смог утащить. Для этого был придуман некий «кошелек» с названием ZenZefi.
Он хранит сертификаты пользователей в защищенной базе данных, шифрует приватный ключ и старается обеспечить его конфиденциальность. А также проводит разные операции с сертификатами по запросу пользователя. ZenZefi работает также в двух режимах: AfterSales и Developer.
В режиме Aftersales создается RAS соединение между ZenZefi и Xentry на порту 9204. Xentry в свою очередь обеспечивает связь между порталом Mercedes и ZenZefi для получения сертификатов. Наподобие прокси. Логинимся онлайн и создается связь. При создании сертификата, ZenZefi создает случайным образом приватный ключ, шифрует его и сохраняет с своей базе данных. Далее формируется Certificate Request в виде .csr файла и отправляется через Xentry на сервер. Это как заявление написать. Написали и отдали. Его рассмотрели и если все ок то одобрили. И в ответ прилетает готовый сертификат(публичная часть). Приватный ключ которого не покидает базу данных.
Вторая версия ZenZefi — Corporate работает напрямую с серверами через собственные механизмы. Не требует Xentry. Принцип тот же, с разницей лишь в том что логин и пароль вводится напрямую в ZenZefi.
Вот как-то так, очень кратко, немного запутанно на первый взгляд. Но на самом деле гениально, сделано! 🙂
Развеять мифы хочется, тем кто говорит: — а вот мне знакомый сказал, что он подправил в сертификате цыферки и продлил срок его службы, или другую чухню. Скажу вам по секрету, не слушайте этих болтунов!
Подделать сертификат невозможно! Единственный вариант, заменить сертификат на свой в прошивке блока.
Но все прошивки зашифрованы! В каждом блоке своя тема. Поэтому можно этот вариант даже не рассматривать!
