Перенос всей логики в ключ (Страница 1 из 3)

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

ЗЫ поскольку живых разработчиков защиты на ключах коде я на этом форуме особо не встречал, предлагаю объединить усилия в плане обдумывания различных вариантов защиты, быть может это пойдет на пользу и нам и вам :). Мой скайп iam+neekeetos , без плюса посередине.

Я живой кодер и хочу помочь :)

Правильно ли я понял, что подразумевается ключ семейства Code?

На эти вопросы сходу ответить трудно, т.к. не до конца понятна логика защиты, поэтому я тоже сначала спрошу:
1. 20 конечных автоматов это искусственный элемент защиты или часть функционала защищаемого ПО?

2.

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

3.

Можно ли быть уверенным, что только одна версия программы работает с ключом одновременно? В этом случае можно было бы применить следующий алгоритм:
1. Сохранять зашифрованный загружаемый код (файл *.cexe) в теле программы.
2. При запуске программы проверять текущую версию загруженного кода в ключе.
3. Если версии не совпадают обновлять загруженный код с помощью GrdCodeLoad.

Это бы позволило обновлять файл программы привычным способом, не усложняя этот алгоритм использованием TRU.

Ничего не хочу сказать, но эта фраза примерно как из документации по гварданту и провоцирует бездумное использование ключей. Например есть алгоритмы GSII64, ECC160, HASH64, RND64, подразумевается что их можно использовать для защиты программы, но нигде нету исходников или даже малейшего описания их свойств. Известно лишь что они все основаны на общем алгоритме. Теперь первый вопрос - должны ли мы в данном случае защищать собственно сами алгоритмы шифрования? Верный ответ - если алгоритм имеет подтвержденную надежность - то не должны, единственный секрет который должен существовать - это ключ шифрования. Попытка скрыть их содержимое косвенно говорит о слабости алгоритмов - разработчик считает, что такого рода секретность добавит надежности, следовательно не обладает достаточной уверенностью в нем, не имел возможности проверить либо скрывает секретные закладки (или банально дыры), позволяющие его взломать по требованию.

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

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

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

Это практически весь функционал.

Входные параметры передаются в автоматы (код). А на выходе перечень номеров (последовательность) реальных функций, которые надо выполнить. То есть в ключе логика, основанная на внешних воздействиях, идущих от датчиков устройств, тайм-аутов ожидания неких сигналов извне, которые не приходят, внешних событий. Из этой логики рождается перечень того, что нужно делать - какие воздействия посылать на устройства - исполнительные механизмы. Пример - мы подаем сигнал, что купюра подана и распознана, состояние одного автомата из ожидания купюры переходит в состояние купюра подана, другой автомат переходит из состояния нет номинала в 1000 рублей. Далее автоматы анализируют, могут ли они дать сдачу и принимают решение отдать купюру назад или принять в кассету. Дается команда на прием в кассету - команда возвращается в выходном списке. Дается уже во внешней программе команда на устройство принять купюру. В коде стартует таймер. Если купюра нормально дошла до места - генерируется новое вх воздействие, где это видно и автомат переходит в состояние купюра принята, если на протяжении какого времени нет сигнала что купюра дошла дол места - срабатывает таймер и осуществляется переход в состояние купюра застряла. На самом деле логика конечно сложнее, но как пример. Насчет работы функций (выходных воздействий) - мы просто подаем в порт нужного устройства команду. Затем если чтото пришло от устройства - обновляем входы или генерим событие, в разных случаях по разному. Из-за того, что многие команды по тайм-аутам даются - надо вызывать автоматы как можно чаще с событием "Типа вроде ничо не происходит". Но всегда что-то происходит.

Вообще то тема про ключи Code и всторенный код, причём тут перечисленные алгоритмы? Если кто-то использует в проекте ключ этого типа, и не помещает в него собственный код - ему можно только посочувствовать!

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

Секретный ключ алгоритма и так хранится только в ключе, и никогда его не покидает!

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

Ну раз вы внимательно читали документацию, помните как происходит обновление пользовательского кода в ключах? Наверно вы используете абсолютно непровереный алгоритм цифровой подписи ECC160 на основе хэша и сам алгоритм не разглашается. Обратите особое внимание что ЕСС это не нормальная подпись, это нечто собраное из их собственного алгоритма блочного шифра. Грубо говоря даже схема подписи вызывает сомнения, даже если не принимать во внимание алгоритмы шифра и хэша, которые там используются.

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

Есть такая методика еще цезарь использовал, называется сегодня security by obscurity, ака безопасность обеспечивается неразглашением. Но только вы почему то не дошли до финальной стадии, зачем все ключи и прочее, просто  СКРЫВАЙТЕ СВОЮ ПРОГРАММУ! :)

Это утверждение верно не во всех случаях. Для "обычного" использования криптографии, как то защита обмена сообщениями между двумя доверенными абонентами это утверждение справедливо.
В защите софта доверенным абонентом является только ключ, а само приложение считается априори скомпрометированным. Поэтому классические подходы тут не работают и сокрытие алгоритма в данном случае эффективно.

Ну и хочется напомнить, что в ключах Guardant Code реализованы опубликованные алгоритмы: AES и SHA256. От этого что-то радикально изменяется?

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

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

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

Как я уже говорил, сделать алгоритм и скрыть рассчитывая, что это усложнит его взлом, противоречит вообще азам криптографии, вот смотрите в википедии например:

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