[toweroff 0]

Добрый день!

 

Сразу поясню - это не задача, а оценка возможности :)

 

Ситуация следущая: есть устройство, для обновления (и проверки своей версии) может самостоятельно обращаться к хосту. Хост смотрит на заголовок от устройства (в котором передается информация о текущем состоянии, версии прошивки и т.д. + некая уникальная последовательность)

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

Сам блок данных шифруется AES128-CBC

 

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

 

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

 

(если не туда запостил, перенесите, пожалуйста, по адресу :) )

[kolobok0 0]

... это не задача, а оценка возможности :)...

 

что такое кодирование - это сокрытие инфы, "с пониженным требованием к взаимодействующим узлам". у вас мк защищён (проблемы с вскрытием прошивки пока не рассматриваем). т.е.

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

имеет бинарное представление, то понять что это такое уже не так просто...

 

по поводу вопроса.

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

перебора и вперёд.. даже при таком подходе, время было не маленьким... месяцы, если не ошибаюсь...

 

и ещё ремарка.

делать некую магическую последовательность - не совсем гут...

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

Изменено 30 сентября, 2014 пользователем kolobok0

[toweroff 0]

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

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

 

и ещё ремарка.

делать некую магическую последовательность - не совсем гут...

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

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

 

 

[alexPec 3]

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

 

А если тот кто закачивал, не получил подтвеждения что CRC в порядке, а реально он поменялся? Пробуем и старый и новый вариант? Это уже как то "бабушка на двое сказала". Хотя конечно это вопрос протокола, но лично я тоже против таких перешивок, когда нельзя в любой момент гарантированно связаться с девайсом, пусть с каким-то секретным-секретным ключом.