Введение в тему:
Имеется система сервер-программа-устройство клиент, все они общаются друг с другом криптованными данными.
Поток данных сервер <-> устройство проходит транзитом через программу с перепаковкой, сами данные при этом не изменяются. Потоки данных сервер <-> программа и программа <-> устройство полностью изучены, возможно посылать им криптованную информацию и получать на неё ответы.
Прямой доступ есть только к коду программы, остальные две стороны - черные ящики.

Схема начала криптообмена сервер-программа:
- import openssl_key to rsa_key (openssl_key short 140 bytes)
- create symmetric CBC key for cipher AES128 with random IV (16 bytes) and const pseudorandom key (16 bytes)
- encrypt RSA key: in const pseudorandom key with random prng to SHA256 for rsa_key
- отправка криптованного ключа на сервер
Таблица векторов IV у клиента(программа) фиксирована 16 * 16 байт, другая информация на сервер не передается, далее идет только крипт/декрипт пакетов.

Схема начала криптообмена программа-устройство:
- import openssl_key to rsa_key (openssl_key long 609 bytes)
- устройству дается команда, на которую оно высылает encrypted RSA key (128 bytes)
- decrypt RSA key to hash SHA256 from rsa_key
- create symmetric CBC key for cipher AES256 with const IV and decrypted RSA key
Таблица векторов IV в программе фиксирована 16 * 16 байт и отлична от таблицы векторов для сервера, другая информация на сервер не передается, далее только крипт/декрипт пакетов.
Эти схемы привел только для того чтобы было понятно какие крипто алгоритмы задействованы.

Задача: декриптовать данные в потоке обмена данных с устройством.
В этом случае имеем следующее:
- инициатором криптообмена всегда выступает устройство
- первый пакет данных на сервер состоит из двух частей фиксированной длины, первая часть постоянная размером 11 байт (её структура: 1ый байт 01, далее 8 байт назовем как серийный номер устройства, т.к. у разных устройств эти данные отличаются, 10-11 байты 0080), вторая часть пакета размером 448 байт уникальна для каждого сеанса криптообмена
- сервер всегда отвечает на первый пакет от устройства даже если этот пакет был подменен и взят от старого сеанса связи
- ответ сервера имеет фиксированный размер 384 байта, но информация в ответе уникальна для каждого ответа
- на отправленный 2ой пакет от старого сеанса связи сервер уже не отвечает

Вопрос: возможно ли на основе этих данных вычислить symmetric CBC key для потока данных сервер <-> устройство?

-----
Everything is relative...

| Сообщение посчитали полезным:

f13nd
Т.е. вы хотите сказать, что устройство, как и сервер имеют по 2 симметричных CBC ключа, один для расшифровки, а другой для шифровки? Или я вас не понял, в стандартном симметричном шифровании используется один ключ как для шифровки, так и расшифровки, в противном случае это уже асимметричное шифрование и ему таблица векторов IV не нужна.

-----
Everything is relative...

| Сообщение посчитали полезным:

Vamit пишет:
в стандартном симметричном шифровании
Я вообще ни разу не видел, чтобы устройство общалось с сервером напрямую. Это уже нестандартно. Столько возможностей обойтись и без этого. На ARM Cortex ключи guardant делают и нормально там все с этим. Я не знаю какого характера там данные, но давать генерировать ключ клиентской стороне, пусть даже в защищенном устройстве, неразумно. Хотя бы затем, чтоб нельзя было его эмулировать, отправляя сообщения сохраненной сессии.

ЗЫ: в любом случае для сервер-устройство RSA ключей нет, очень наивно предполагать, что они будут те же, что для сервер-программа или программа-устройство.

-----
2 оттенка серого

| Сообщение посчитали полезным:

очень наивно предполагать, что они будут те же, что для сервер-программа или программа-устройство
Я и не предполагаю, т.к. эти варианты уже проверены и они не работают. Осталось 2 варианта: или обе стороны имеют один и тот же openssl_rsa_key, который нам неизвестен или генерят ключи самостоятельно.

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


471f_06.11.2018_EXELAB.rU.tgz - TransferMode0-1.txt

-----
Everything is relative...

| Сообщение посчитали полезным:

Vamit пишет:
Сообщения кодированы, но не кратны 16
Ну тут что угодно может быть, только гадать остается.

-----
2 оттенка серого

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

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

-----
2 оттенка серого

| Сообщение посчитали полезным: ajax

Вообще то не в тему но посмотрите как происходит соединение устройств по WIFI(EAPOL) , навряд ли что здесь реализовано что то своё,

-----
Чтобы правильно задать вопрос, нужно знать большую часть ответа. Р.Шекли.

| Сообщение посчитали полезным:

Vamit пишет:
Т.е. вы хотите сказать, что устройство, как и сервер имеют по 2 симметричных CBC ключа, один для расшифровки, а другой для шифровки? Или я вас не понял
В конструировнии протоколов связи - так делать хорошая практика. Ещё лучше - четыре симмитричных ключа. Ещё два - для выработки иммитовставки, один на приём другой на передачу.

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

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным: Vamit, 4kusNick

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

-----
Everything is relative...

| Сообщение посчитали полезным:

OFFTOP
Vamit пишет:
а это ещё пока никто не умеет..
Посмотрите видео, оно может изменить ваше представление об умениях людей:
https://www.youtube.com/watch?v=nap0gtds5tQ

f13nd пишет:
Здесь даже не послойное сканирование изображено
Послойное сканирование в ролик на ютубе уместить сложно, согласитесь. Про видео - ничего сверхъестественного, кроме того, что схемы A8 в публичном доступе до сих пор нет нигде, есть несколько неполных схем и все. Они знали куда и зачем они лезут.

f13nd пишет:
на уровне индуса, который на коленке дедовским паяльником может BGA проц перепаять.
хотел бы я на это посмотреть вживую, особенно на плате с 10-ую слоями и тонкой как два листа картона сложенных вместе)))

| Сообщение посчитали полезным:

Katana пишет:
Посмотрите видео, оно может изменить ваше представление об умениях людей
Здесь даже не послойное сканирование изображено, в кристалл они не лезли. Растворили кислотой краешек кожуха, чтоб до дорожек на текстолитовой подложке добраться. Что-то на уровне индуса, который на коленке дедовским паяльником может BGA проц перепаять.

Добавлено спустя 25 минут
Katana пишет:
ничего сверхъестественного, кроме того, что схемы A8 в публичном доступе до сих пор нет нигде
Они нашли CPU to U0301 B1 и CPU to U0301 B2 пины, соединенные с другой микрухой я так понял. Проц BGA, видимо поэтому и все эти пляски были. Но как бы найти что с чем соединено может и выпускник ПТУ имея неисправный айфон и тестер на руках.

Добавлено спустя 40 минут
Katana пишет:
хотел бы я на это посмотреть вживую, особенно на плате с 10-ую слоями и тонкой как два листа картона сложенных вместе
Никогда ничем подобным не занимался. Но если бы пришлось, точно так же раствори бы кожух, снял бы камень. И бруском от веневских алмазов стачивал бы по слою и фотографировал. Мне эта задачка не кажется нереальной.

-----
2 оттенка серого

| Сообщение посчитали полезным:

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

-----
PGP key <0x1B6A24550F33E44A>

| Сообщение посчитали полезным: