Вскрыть AES128_KEY и iv, Насколько реально? Опции

[toweroff]

Добрый день!

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

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

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

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

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

[kolobok0]

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

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

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

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

Сообщение отредактировал kolobok0 - Sep 30 2014, 10:20

[toweroff]

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

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

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

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

[alexPec]

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

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