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

В общем так:

В защищенной ячейке вектор начальных состояний автоматов (20 чисел, каждое число - номер состояния соотв. автомата) Y0.
В Алгоритме типа код - несколько автоматов, скажем 3 из 20-ти.

В коде в постоянной памяти хранится текущее состояние автоматов вектор Y,
вектор новых состояний Y*, текущие входы вектор X и выходы вектор Z.

При инициализации кода Y = Y0

Сам Y можно передавать по изменению - только те, которые поменялись + вектор номеров

Далее
- формирую входной буфер в ПК, состоящий из (X,Y)
- кодирую его с помощью ключа, получаемого из X или Y ? (X,Y)->(XY)'
- вызываю код C(XY')
- в ключе расшифровывается (X,Y)'->(X,Y) с помощью того же алгоритма и того же ключа (X или Y)
- Выполняются автоматы (Y*,Z)=A(X,Y)
- таким же (ключом X или Y или туда Y назад X) образом кодирую выходной буфер (Z,Y*)->(Z,Y*)'
- возвращаю управление на ПК
- расшифровываю с помощью X или Y (Z,Y*)'->(Z,Y*)
- Y=Y*
- выполняю Z

Остальные автоматы выполняются как обычно.

Может сюда еще как-то цифровую подпись прилепить?

Сам код, если в нем не используются криптографические функции, не очень большие циклы и т.п., выполнится довольно быстро. Можно
даже примерно посчитать, исходя из производительности контроллера ключа. Большие накладные расходы дают операции ввода-вывода и шифрование/подпись трафика, то есть сам вызов кода в ключе и получение от него результатов. Эти операции могут занимать десятки (а может и сотни) миллисекунд.

TRU в Guardant Code реализован на AES и SHA256

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

В самостоятельной смене кодов доступа нет никакого смысла.

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

вобщем тогда програмлю по схеме приведеной выше ...

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

Samples\ARM\05 - LED Control\

Там кроме мигания светодиодом ничего нет.

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

Известные мне этапы работы функции GrdCodeRun:
1. Шифрование входного буфера (выполняется в коде API на PC)
2. Передача по USB
3. Расшифровка входного буфера (выполняется в ключе)
4. Вызов пользовательского кода (выполняется в ключе)
5. Шифрование выходного буфера (выполняется в ключе)
6. Передача по USB
7. Расшифровка выходного буфера (выполняется в коде API на PC)

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

Я делал замеры на ключах Code первого поколения.
1. Сделал 5 версий загружаемого кода, в которых выполнялась простая мат.операция, в первом 1 раз, во втором 10 раз, в третьем 100 раз и т.д.
2. Далее выполнил каждый из них 100 раз, откинул одно самое долгое выполнение для каждой прошивки, чтобы хоть как-то уменьшить погрешность в многопоточной среде.
3. Вычислил для каждой прошивки среднее время выполнения.
4. Составил систему уравнений, где Y - время выполнения моего кода в ключе (этап 4), X - накладные расходы на вызов этого кода (этапы 1-3,5-7):
    X + 1*Y = t1
    X + 10*Y = t2
    X + 100*Y = t3
    и т.д.

На моей машине X получился около 20 мс, а Y был настолько мал, что терялся в погрешности измерений, оказывая влияние только в 100 и более итерациях.

Нынешнее второе поколение ключей должно работать быстрее, т.к. ускоряются шаги 3 – 5.
Но мне вполне хватало и тогдашних показателей.

PS. OMG! 38 новых сообщений из них 4 по теме :)

Это чтоб я не расслаблялся :)

Вот собственно этим я и займусь. Продумал сегодня всю защиту в деталях, думаю что будет супер. А главное, что экзешник можно распространять и не бояться - вся логика то в ключе!!! Без ключа вообще непонятно как ломать прогу, проще новую написать :)