История изменений

Мир (и автомобили) меняются. ftp тоже когда-то идеально подходил для передачи файлов, но почему-то сейчас почти повсеместно вытеснен sftp или аналогами. Понимаете аналогию?

Аналогия плохая, т.к. там где служит CAN ничего лучше особо не придумать. Любое усложнение там во вред.

И как введение шифрования и подписей снизят надежность? Вы же не станете утверждать, что, например, telnet надежнее ssh по причине отсутствия шифрования?

CAN - шина достаточно шумная, и текущая реализация - это по сути дела очень маленькие пакетики по 4-8 байт полезной нагрузки. (Но бывает и больше). потеря одного бита обычно не сказывается на передаче, т.к. избыточная кодировка эти потери сглатывает. Если мы будем шифровать, пусть даже самым примитивным образом симметричным шифрованием, шифрование добавить как минимум байта 32 на каждый пакет (16 байт - IV, 16 байт - подпись, она же authentication code), это уже превратит минимальный пейлоад с 4 до 36 байт. Вероятность того, что пакет получит больше ошибок, чем справится избыточное кодирование - заметно возрастает с длинной. Более того сам поток данных заметно увеличится. Так что вам вместо пары толстых медных проводов, уже потребуется что-то помехо-защищенное, и так что бы еще ваша помехо-защищенность была устойчива и к вибрациям, и к перепадам температур и к аггресивным средам. Так что - применимо к автомобилям - надежность снизится.

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

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

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

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

Я так и не понимаю, какие с Вашей точки зрения минусы в программной реализации этих самых карантинных мер? Плюсы лично для меня очевидны - в первую очередь, это гораздо большая гибкость решения.

Я как человек с 15 годами стажа профессионально разработки - не верю в надежность софтверных решений. В софте рано или поздно находят уязвимости. Взломать «дубовый аппаратный» карантин куда сложнее.

P.S. Если где ошибки в «русская языка» – извиняйте, пишу по русски редко.

Мир (и автомобили) меняются. ftp тоже когда-то идеально подходил для передачи файлов, но почему-то сейчас почти повсеместно вытеснен sftp или аналогами. Понимаете аналогию?

Аналогия плохая, т.к. там где служит CAN ничего лучше особо не придумать. Любое усложнение там во вред.

И как введение шифрования и подписей снизят надежность? Вы же не станете утверждать, что, например, telnet надежнее ssh по причине отсутствия шифрования?

CAN - шина достаточно шумная, и текущая реализация - это по сути дела очень маленькие пакетики по 4-8 байт полезной нагрузки. (Но бывает и больше). потеря одного бита обычно не сказывается на передачи, т.к. избыточная кодировка эти потери сглатывает. Если мы будем шифровать, пусть даже самым примитивным образом симметричным шифрованием, шифрование добавить как минимум байта 32 на каждый пакет (16 байт - IV, 16 байт - подпись, она же authentication code), это уже превратит минимальный пейлоад с 4 до 36 байт. Вероятность того, что пакет получит больше ошибок, чем справится избыточное кодирование - заметно возрастает с длинной. Более того сам поток данных заметно увеличится. Так что вам вместо пары толстых медных проводов, уже потребуется что-то помехо-защищенное, и так что бы еще ваша помехо-защищенность была устойчива и к вибрациям, и к перепадам температур и к аггресивным средам. Так что - применимо к автомобилям - надежность снизится.

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

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

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

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

Я так и не понимаю, какие с Вашей точки зрения минусы в программной реализации этих самых карантинных мер? Плюсы лично для меня очевидны - в первую очередь, это гораздо большая гибкость решения.

Я как человек с 15 годами стажа профессионально разработки - не верю в надежность софтверных решений. В софте рано или поздно находят уязвимости. Взломать «дубовый аппаратный» карантин куда сложнее.