Вот почему я против засилья микросхем и процессоров в автомобилях

А так – эти две системы вполне могут сосуществовать в автомобиле, абсолютно не пересекаясь.

А как же интеграция? Когда, например, повышение оборотов сопровождается усилением громкости музыки? Или на приборную модель выводят название композиции?

Когда, например, повышение оборотов сопровождается усилением громкости музыки?

Это реально где-то реализовано так? Что-бы знать какую марку автомобилей никогда не покупать..

Или на приборную модель выводят название композиции?

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

Ты сейчас рассуждаешь о том, чем бы была бабушка, будь у нее яйца. Вот когда будет - тогда посмотрим.

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

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

Меня напрягает сочетание а) Существующей возможности изменять механические параметры автомобиля перепрошивкой по воздуху (пруфец я уже прилагал, так что это свершенное событие а не фантазия); б) Существующей возможности взломать КОМПАНИЮ снаружи (пруф в новости, и это не случайный взлом из ряда «секретутка смотрела порно и подцепила троян», нет, это взлом компании); в) Теоретической возможности переписать прошивку имея доступ к серверам компании и незаметно перепрошить автомобили так, что это компании это будет неизвестно, а для клиента включая ПО машины это будет выглядеть как очередной апдейт.

Так-то.

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

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

Я знаю что автомобили защищены какой-нибудь цифровой подписью, шифрованием CAN-шины и так далее и тому подобное.

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

То, о чем я говорю - физическое разграничение сетей отвечающей за критические узлы и развлекательных - вполне можно реализовать, было бы желание у производителя. До недавнего времени этого особо в принципе и не требовалось, т.к. не было такого прямого беспроводного доступа к системам автомобиля, но со временем возможно к чему-то такому прийдут, после пары десятков инцидентов со взломом. (А еще будет эпичным увидеть ransomware на автомобиле - «ваш автомобиль заблокирован, отправьте 0.05 BTC по такому адресу что бы разблокировать»).

А про доступ через магнитолу – было время, я через разьем на магнитоле на моей пред-пред-предыдущей Peugeot 206 читал обороты двигателя и прочую телеметрию, через самодельный сниффер на atmega. Там правда не CAN шина, а некий аналог от PSA под названием VAN (Vehicle Area Network), но по своей структуре протокол очень очень похожий, можно сказать слизан с CAN.

Это реально где-то реализовано так? Что-бы знать какую марку автомобилей никогда не покупать..

Я точно видел такое, но конкретной модели сейчас не назову.

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

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

физическое разграничение сетей отвечающей за критические узлы и развлекательных

Но зачем? Может, лучше подумать об улучшении протокола CAN? Или вообще его замене на что-то более защищенное?

Но зачем? Может, лучше подумать об улучшении протокола CAN? Или вообще его замене на что-то более защищенное?

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

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

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

А авто значит может удаленно на ходу шиться? Т.е для самолетов элементарная логика безопасности есть, а для авто делать не стали, да?

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

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

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

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

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

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

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

и все что требуется - не пускать в эту песочницу ничего извне без карантинных мер.

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

На уровне софта как раз будет плохо.

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

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

Ну почему же глупости. Как вы заметили ранее я говорю о теории, а вы сугубо о практике. В данном случае (согласто ст. 192 ТК РФ) работадатель занимается самоуправством. Потому что согласно той же статье ТК единственные меры дисциплинарного воздействия на работника это 1) замечание, 2) выговор, 3) увольнение. Любое другое взыскание – противозаконно и очень легко оспаривается в суде. То что так поступают многие работадатели и еще большее кол-во работников принимают это и не идут в суд не делает это законным.

вместо штрафа просто не дать человеку премию, которую он обычно получает.

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

штрафовать можно за любое нарушение этих документов

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

В России либо это разрешено официально, либо запрет на штрафы элементарно обходится (см. выше). В любом случае, это довольно широко распространенная практика.

Еще раз говорю вам, в РФ есть ст. 192 ТК, которая говорит буквально следующее:

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

1. замечание;
2. выговор;
3. увольнение по соответствующим основаниям.

[…]

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

На мой взгляд проблема лишь в том что большинство людей считает подобные нарушения нормой и не идут жаловаться. Ну тут уж ССЗБ.

Это можно всегда было сделать на любой модели автомобиля.

В Барселоне/Париже не так давно убили гораздо больше людей с помощью автомобиля. Можно просто выехать на променад и давить всех подряд.

если токарь Вася угробит станок по пьяни, то премии не будет?

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

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

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

Не думаю, что в ЕС что-то принципиально отличается.

В ЕС очень сильно отличается. При любом разборе суд однозначно и с первой минуты встает на сторону работника. Доказать что-то предельно сложно, долго и дорого по деньгам. Настолько, что, как правило, бессмысленно. Гораздо проще заплатить все что должен и пожелать доброго пути.

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

Если не секрет, сколько могут дать за смену MAC-адреса?

Понятия не имею. Сам мак адрес меняю именно в ситуации описанной вами.

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

предлагают и снятие ограничений на число оборотов двигателя. Причем заметьте, чисто программно, без какой-либо перепайки.

Я имею в виду другое. Вот допустим есть два двигателя один 10 000 rpm, а другой 7 000 rpm. Вот эти обороты зашивают в ROM, просто потому, что если крутить двигатель 7К rpm, на 10К rpm, то он конструктивно разрушится. Вот это ограничение обычно идет в ring0.

Другое дело что по каким-либо причинам двигатель 7К rpm ограничен на 5К rpm, экология там и все такое. Это скорее всего будет зашито в ring1 и можно будет обойти прошивкой.

Я сам не эксперт и может уже по-другому делают, но удивлюсь если это поменялось.

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

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

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

Ну так именно эту проблему и нужно решать, а не заливать эпосидкой разъем для гарнитуры ;).

Хех, а вы ни разу не видели сервер с удаленными USB/PS2 разъемами? В смысле удаленными кусачками. Запрещено политикой безопасности и все.

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

А почему вы пиписываете мне то, чего я не говорил? Я говорил об физических способах ограничения того, какая информация может поступать в защищенную систему извне, а не об «выдернуть провод».

Ведь по сути, все что требуется передать внутрь защищенной системы - это набор boolean значений, «нажата / отпущена кнопка», ну скажем еще пара int-ов для положний разных «крутилок».

Это все можно сделать на аппаратном уровне, как N-битная шина на входе, где каждому boolean-у или кадому биту int-а выделена отдельная физическая линия, потом примитивная схема со сдвиговым регистром - два провода на выходе, идущие в защищенную систему, там аналогичная примитивная цифровая схема со сдвиговым регистром + пара flip-flop-ов, для сохранения последнего значения. И все. Никакого софта, и значения кнопок на панели управления мы прокинули с минимум затрат и минимум рисков.

И чем такя система лучше sshd? Тем что если взломают sshd из-за zero day, то никто не может погибнуть в аварии. А если взломают автомобиль - такая вероятность есть.

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

Извините, но это не так. Попробуйте передать 1Тб данных по сети 10Gbit, внезапно вы обнаружите что sftp в 10-30 раз медленнее чем ftp с прикрученным поверх сертификатом TLS и шифрованием.

Пу сути sftp это костыль, а ftp это решение для передачи файлов. Модернизированное с помощью TLS для обеспечения должной безопасности.

Хех, а вы ни разу не видели сервер с удаленными USB/PS2 разъемами? В смысле удаленными кусачками. Запрещено политикой безопасности и все. Раньше меня это тоже сильно забавляло, но со временем понял что решение-то не такое и плохое, потому что разгружает инженеров по эксплуатации, а именно не надо настраивать ничего связанного с защитой этих портов, следить, обновлять и т.д.

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

Мир (и автомобили) меняются. 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 или аналогами. Понимаете аналогию?

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

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

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

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

Сыграет. Многие системы двигателя требуют мгновенной реакции на событие. Датчик положения распредвала замкнулся - послал сигнал на ЭБУ, спустя 130мс нужно подать напряжение на 32мс форсунку №2, подождать 90мс, а потом на 200мс подать напряжение на свечу №2. И все эти мс должны быть строго соблюдены, иначе двигатель будет троить или вовсе заглохнет. И это еще не самый быстродействующий механизм, есть еще быстрее. Например SRS. При столкновении, подушка безопасности должна улететь в ваше лицо быстрее, чем ваше лицо достигнет руля , это реально миллисекунды.

А что самое интересное - из-за интеграции этих систем, шифрование нельзя сделать выборочно. Можно или везде, или нигде.

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

А ты точно про миллисекунды? Твои цифры даже для ПК с Linux не проблема (тоже удивлялся почему часть систем машинки было сделано на хедюните).

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

А ты точно про миллисекунды? Твои цифры даже для ПК с Linux не проблема

Я точно про миллисекунды, хотя ты немного не на то обратил внимание. Речь шла о ТОЧНЫХ и СТАБИЛЬНЫХ временных интервалах. И эти временные интервалы касаются не одного узла, а сразу нескольких, потому что информацию надо передать дальше.

Что касается ПКов на Linux, то проблемы там начинаются когда нужно сделать что-то типа software PWM, и тогда резко выясняется что импульсы длительностью в 80мс начинают нещадно жечь проц в хвост и гриву, а если systemd в этот момент приспичит записать лог, то длительность уже будет не 80мс, а 90мс.

В automotive немного другие требования к «стабильности».

Впрочем весь этот дроч существует только из-за\для газораспределительного механизма, и электродвиглы полностью лишены этих недостатков.

Но тем не менее ЛЮБОЕ усложнение критичного узла, вносит задержки в его работу и вероятность сбоя. А в случае автомашин, оно просто не нужно - ты ведь не ставишь пароль при загрузке своего Kodi или SmartTV? Я - нет, потому что пульт от телека - у меня )))

И чем такая система лучше sshd?

Лично я считаю, что она хуже ;). И вот почему. Если в будущем Вам потребуется расширить функциональность (передать дополнительную информацию между «закрытой» и «открытой» частями системы), то в Вашей модели все придется переделывать на уровне железа. Тогда как в условном аналоге sshd достаточно будет обновить софт.

Тем что если взломают sshd из-за zero day, то никто не может погибнуть в аварии.

Предлагаю Вам вспомнить теорию вероятностей. Вероятность обнаружения и эксплуатации уязвимости zero day чрезвычайно мала. На несколько порядков меньше вероятности гибели людей в «обычных» ДТП (произошедших по вине водителей). Чтобы убедиться в этом, можете просто сравнить число жертв ДТП за год в мире и число обнаруженных (пусть даже просто обнаруженных, а не успешно использованных для атаки) уязвимостей zero day в автомобилях. А дальше вспомните про сложение вероятностей. Если к одной десятой процента прибавить одну стотысячную, по факту ни чего не изменится.

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

Попробуйте передать 1Тб данных по сети 10Gbit, внезапно вы обнаружите что sftp в 10-30 раз медленнее чем ftp с прикрученным поверх сертификатом TLS и шифрованием.

Я так думаю, результат будет от железа зависеть ;). Не имел пока дела с сетями 10 Gb, но подозреваю, что на современном железе разницы между ftp и sftp не будет.

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

Мне сложно спорить предметно - представления о CAN у меня довольно смутные :(. Но честно говоря, ни разу не встречал идеальных систем, где улучшать было просто нечего. И очень сомневаюсь, что CAN является тем самым исключением из общего правила.

CAN - шина достаточно шумная, и текущая реализация - это по сути дела очень маленькие пакетики по 4-8 байт полезной нагрузки

Ну вот видите, а говорите, идеальная шина, которую не улучшить ;). Как минимум, можно шумность понизить.

Так что вам вместо пары толстых медных проводов

Вы это всерьез пишете, или просто издеваетесь? «Пара толстых медных проводов» в состоянии передавать мегабитные потоки (вспомните времена DSL). А Вы сокрушаетесь о десятках байт. Там запас емкости канала в несколько порядков. И причем тут вибрации или перепады температуры в несколько десятков градусов? Пока нет потери контактов все это практически никак не сказывается на передаче данных.

Более того сам поток данных заметно увеличится.

Ну да, увеличится. Ну и что? См. выше про запас пропускной способности.

CAN шина преспокойно справляется с этой зашумленностью в текущей реализации.

Это не означает, что гипотетический CAN v 2.0 с шифрованием не сможет с этим справиться.

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

Вот с этого и надо было начинать :). Вера, как известно - иррациональное понятие. Логические аргументы в таких случаях бесполезны :(.

Я так думаю, результат будет от железа зависеть ;)

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

На реально больших объемах передачи sftp сливается.

Лично я считаю, что она хуже ;). И вот почему. Если в будущем Вам потребуется расширить функциональность (передать дополнительную информацию между «закрытой» и «открытой» частями системы), то в Вашей модели все придется переделывать на уровне железа. Тогда как в условном аналоге sshd достаточно будет обновить софт.

И как часто в автомобиле после обновления ПО появляется ещё одна физическая кнопка на панели?

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

во вторых как я уже написал, факт взлома уже свершился

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

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

Угу, осталось рассказать, что на роутер Вы тоже заходите по telnet - кого в локальной сети бояться-то?

А если серьезно, Вы уверены в безопасности подобного подхода? Если хакер Вася из соседнего дома влезет к Вам в WiFi-сеть и запустит сниффер?

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

Увы, но пока мы не перешли окончательно на автопилоты, причинами основных задержек в правлении автомобилем являются именно люди :(. И на этом фоне все остальные задержки просто несущественны.

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

Все верно, но мы-то с Вами говорим о микросекундах. Ну будет напряжение на форсунке не 32, а 32.1 мс, уверен, двигатель этого даже не заметит.

Можно или везде, или нигде.

Согласен. И не вижу никаких препятствий делать его везде. Про задержки см. выше.

Вот с этого и надо было начинать :). Вера, как известно - иррациональное понятие. Логические аргументы в таких случаях бесполезны :(.

Скажу иначе: мой опыт говорит о том, что 95% софта - дырявое г**ище. И если где дыр не нашли - скорее всего плохо искали.

При прочих равнах FTP всегда будет быстрее на любом железе, потому что придуман именно для передачи файлов (например при подключении ему выделяется отдельный порт для данных). SFTP это просто обвесок для SSH чтобы легче было конфиги Wordpress редактировать.

Причем тут отдельный порт? Разница в скорости прежде всего обусловлена шифрованием. Если железо достаточно мощное, то время, тратящееся на шифровку/дешифровку пакета существенно (в 10 и более раз) меньше времени, необходимого на его передачу. Если это условие выполняется (а это прямо зависит от вычислительных возможностей железа), то разница между ftp и sftp будет пренебрежимо малой.

Я хорошо помню времена, когда на слабых роутерах включение шифрования просаживало даже 100 Mb-ные каналы. Но как только вычислительные мощности роутеров выросли, эта просадка исчезла.

И как часто в автомобиле после обновления ПО появляется ещё одна физическая кнопка на панели?

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

А по поводу кнопок - заказал на AliExpress, сейчас жду, когда привезут ;).

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

Причем тут отдельный порт?

Как пример, там еще много не очевидных решений.

Если железо достаточно мощное,

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

Я хорошо помню времена, когда на слабых роутерах включение шифрования просаживало даже 100 Mb-ные каналы.

А сейчас другие времена? Кто в здравом уме будет шифровать данные на устройстве передачи данных? То есть на OpenWRT конечно можно запилить хоть шифрование, хоть торренты. В каком-либо серьезном окружении это недопустимо. Распределение обязанностей и все такое.

И если где дыр не нашли - скорее всего плохо искали.

А как же программы с математическим доказательством отсутствия дыр? ;)

А как же программы с математическим доказательством отсутствия дыр? ;)

Это которые биткоинты?

А сейчас другие времена?

Конечно :).

Кто в здравом уме будет шифровать данные на устройстве передачи данных?

Любой, кто организует туннели (ipsec, openVPN, pptp, etc) - все они так или иначе поддерживают шифрование.

В каком-либо серьезном окружении это недопустимо. Распределение обязанностей и все такое.

Что-то я Вас не понимаю. Кому же еще заниматься туннелями, как не роутерам? IMHO, это их прямая обязанность.

Это которые биткоинты?

Это про доказательное программирование ;).

А как же программы с математическим доказательством отсутствия дыр? ;)

Много вы знаете ОС написанных таким образом?

Много вы знаете ОС написанных таким образом?

Я не знаю (не специалист), но вроде программировать микроконтроллеры - не тоже самое (по объему кода), что писать OS общего пользования? Это я к тому, что чем меньше кода, тем проще, наверное, обходиться без ошибок. Разве не так?

Я не знаю (не специалист)

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

Пока что случился факт взлома сети на производстве автомобилей.

Ну так ведь и spectre с meltdown случились пока что в лабораториях, странно почему весь мир решил патчиться. Да и ваша вечно открытая дверь в квартиру может пока что не привлекать воров, почему же тогда держите ее закрытой?) Выходит по вашей логике «вот когда вас убьют, тогда и звоните».

Угу, осталось рассказать, что на роутер Вы тоже заходите по telnet - кого в локальной сети бояться-то?

Роутер смотрит наружу. Но таки да, на роутер я захожу по HTTP, потому что между мной и ним никого нет, поэтому HTTPS излишен и не нужен.

А если серьезно, Вы уверены в безопасности подобного подхода? Если хакер Вася из соседнего дома влезет к Вам в WiFi-сеть и запустит сниффер?

Уверен. Это внутренняя сеть, наружу она не смотрит.

Увы, но пока мы не перешли окончательно на автопилоты, причинами основных задержек в правлении автомобилем являются именно люди :(. И на этом фоне все остальные задержки просто несущественны.

Как вы все смешали в кучу …

1. Те задержки, причинами которых являются люди - являются такими by design. Именно благодаря таким задержкам, видно что все еще человек владеет автомобилем, а не автомобиль человеком;

2. Кстати вы о каких именно задержках ? Если вы за угол опережения зажигания, срабатывание SRS или ABS - то человека сюда не допускают, он физически не сможет. Если вы за условное кручение руля или нажатие на тормоз, то таки да, я сам хочу решать когда мне тормозить - перед стоп-линией, или на 15 см после нее. Или не тормозить вообще, если у меня в машине мама в состоянии инсульта и жить ей осталось 8 минут.

Все верно, но мы-то с Вами говорим о микросекундах. Ну будет напряжение на форсунке не 32, а 32.1 мс, уверен, двигатель этого даже не заметит.

Вы эт серьезно ? Во-первых, мс - это миллисекунда, стыдно не знать. Во-вторых, погрешность там будет больше чем 0.1 мкс. Даже на относительно мощном RPI который занимается одним лишь PWM и сервисами Linux - разлет бывает плюс минус пол-секунды. В случае с автомобилем такое распездяйство не прокатит - в лучшем случае будет просто перерасход горючего или тройнет, в худшем случае - детонация, повышенный износ и внезапный клин двигателя на дороге. И правда, какая разница, в цилиндр условно 320 миллилитров объема впрыснут 320 миллилитров, или 321 миллилитр )) В самом деле )))

Согласен. И не вижу никаких препятствий делать его везде. Про задержки см. выше.

Кроме отсутствия препятствий, должно быть еще и присутствие целесообразности. Ее - нет. Все эти механизмы находятся внутри машины.

Причем спорите с весьма основополагающими понятиями.

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

Автомобили тут - не более чем частный случай, это утверждение, IMHO, применимо к любым системам.

Ну так ведь и spectre с meltdown случились пока что в лабораториях

Совершенно верно. Именно поэтому считаю истерию вокруг этих уязвимостей искусственно раздутой. Да и патчить надо с умом - во многих случаях этого просто не нужно делать (внутренние защищенные сети).

Уверен. Это внутренняя сеть, наружу она не смотрит.

Т. е. Ваш дом полностью экранирован, и WiFi нигде не выбивается наружу, я правильно Вас понял?

я сам хочу решать когда мне тормозить - перед стоп-линией, или на 15 см после нее. Или не тормозить вообще, если у меня в машине мама в состоянии инсульта и жить ей осталось 8 минут.

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

Во-первых, мс - это миллисекунда, стыдно не знать.

Спасибо, я в курсе :). Рекомендую внимательнее читать то, на что отвечаете.

Во-вторых, погрешность там будет больше чем 0.1 мкс.

Вы это серьезно пишете? Хотите сказать, что относительная погрешность менее 10^-5? Посмотрел в Сети - везде указаны погрешности, как я и написал - в 0.1-0.2 мс.

Даже на относительно мощном RPI который занимается одним лишь PWM и сервисами Linux

Тут дело не в мощности. Тут нужен режим реального времени. Можно и на Linux реализовать.

Ее - нет. Все эти механизмы находятся внутри машины.

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

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

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

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

Но все идет к тому, что машины все больше и больше будут обмениваться сигналами с элементами дорожной инфраструктуры и друг с другом.

Гы. Пока что не светит даже чтобы машины могли батарейками обмениваться (универсальные разъемы и т.д.), полностью решив вопрос зарядки. А вы про какие-то сигналы, друг другу… Но я устал вам объяснять почему этого нет и скорее всего никогда не будет.

Если не верите попробуйте поставить сервер в чистом поле и решить его безопасность с помощью софта.

Если под безопасностью понимать отсутствие несанкционированного доступа к данным, то запросто ;).

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

Так а какой смысл в споре двух дилетантов? А так я ожидаю от спора расширения кругозора ;).

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