Контрольное число

← →
Дмитрий СС (2014-05-22 23:32) [0]

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

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

Например, диспенсер GRG для операций выдачи требует дополнительную контрольную сумму, алгоритм которой не описывается в документации. GRG дает dll-ку для этого.

Хочется сделать способ достаточно открытым:
Например, блок данных дополняется секретным числом (байт 8), которые хранятся в EEPROM устройства, а затем для полученных данных рассчитывается обычная crc32.

Прошу оценить предложенный вариант или предложить чего-нибудь. Спасибо.

← →
Павиа (2014-05-22 23:43) [1]

Как отмазка от начальства сойдёт. А так ваша защита ничто не защищает. Это всего лишь имитация защиты.

← →
Дмитрий СС (2014-05-23 00:15) [2]

> Павиа (22.05.14 23:43) [1]

В данном случае нет начальства.

Я и спрашиваю совета.

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

← →
Rouse__ (2014-05-23 00:29) [3]

Бери любой криптохэш и используй, не 8 байт конечно, но достаточно надежно

← →
Rouse__ (2014-05-23 00:31) [4]

Зы 8 байтный хеш снимется приерно за 6-7 дней только на дампе, если есть доступ к трафику и возможность его изменения, около суток

← →
картман © (2014-05-23 00:34) [5]

Удалено модератором

← →
Rouse__ (2014-05-23 00:35) [6]

Это из практики, ес че ;)

← →
Дмитрий СС (2014-05-23 00:36) [7]

> Rouse__ (23.05.14 00:31) [4]

Сделаем, к примеру, 16 байт. Тогда мне интересно, при расчете crc32 имеет ли вообще значение сколько байт я припишу?
Или все-же взять алгоритм покруче: например, md5? И брать от результата первые 4 байта (16 байт на пакет - многовато)

← →
Rouse__ (2014-05-23 00:39) [8]

Если ты ограничен размером пакета то брось - резать хэши смысла не имеет из-за коллизий

← →
Rouse__ (2014-05-23 00:40) [9]

Стукнись завтра ко мне, расскажу один приват вариант, может он тебе подойдет

← →
Дмитрий СС (2014-05-23 00:55) [10]

ОК! Спасибо!

← →
картман © (2014-05-23 01:01) [11]

Удалено модератором

← →
Inovet © (2014-05-23 01:03) [12]

> [11] картман © (23.05.14 01:01)

Наверноне столько, сколько надо.

← →
Inovet © (2014-05-23 01:04) [13]

> [12] Inovet © (23.05.14 01:03)
> Наверноне

Наверное

← →
картман © (2014-05-23 01:38) [14]

> Inovet © (23.05.14 01:03) [12]
>
> > [11] картман © (23.05.14 01:01)
>
> Наверноне столько, сколько надо.

а если не будет сколько надо? Если за 6-7 дней в дампе будет одно значение? Собсна, я это имел в виду

← →
Германн © (2014-05-23 02:55) [15]

> Прошу оценить предложенный вариант

Бред. Сферического коня так защитить не получится. Тем более в вакууме.
Особенно впечатляет фраза
> Повторюсь, его задача не защита от подделок пакетов, а защита
> от стабильной работы с другими устройствами

Хоть бы на русский перевёл эту задачу.

> а от того, сколько всего будет в дампе - ниче не зависит?

Чем больше тем лучше.

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

> KSergey © (23.05.14 10:53) [17]
> Реверс кода шифрования или просто его выкусывание целиком
> - как бы спасет теоретических взломщиков.

Только в очень простых случаях (ну очень простых).

> Дмитрий СС (23.05.14 00:55) [10]
> ОК! Спасибо!

Кстати Дим, совсем забыл тебе после сегодняшних пояснений про протокол диффи-хеллмана отговорить. Его тебе делать не стоит, он нужен для защиты от MITM, а тут одна из сторон будет под отладчиком и вся суть данного протокола будет нивелирована. Так что работай по той схеме как я объяснил - самый бронебойный вариант.

ЗЫ: ну и просьба - сегодняшние пояснения не выноси на паблик плз :)

Контрольное число Найти похожие ветки