Общие рекомендации

Под надежным прикрытием автоматической защиты вы можете строить свою внутреннюю защиту на основе Guardant API. При этом целесообразнее следовать следующим советам:
1. Не храните в явном виде коды доступа к ключу. Не следует хранить в «чистом» виде Личные коды, по которым производится доступ к электронному ключу. Для того чтобы осложнить хакерам их поиск в теле приложения, Личные коды можно закодировать (например, при помощи операции XOR). Непосредственно перед вызовом функции API раскодируйте их, а после того как функция отработала – сразу же удаляйте из памяти раскодированный вариант Личного кода. Также можно хранить Личные коды частями в разных переменных.
2. Не храните «лишние» коды доступа в защищенном приложении. Например, если приложение использует только чтение из ключа и запуск его аппаратных алгоритмов, нужно хранить в приложении только Личный код для чтения (Private Read Code). Остальные Личные коды не будут нужны, а их присутствие в теле приложения может сильно облегчить хакеру задачу получения доступа к ключу.
3. Располагайте вызовы функций API по всему телу приложения. Это резко увеличивает объем кода, который надо изучить хакеру для локализации кода проверок и его модификации.
4. Организовывайте взаимодействие с электронным ключом из разных потоков. Многопоточные приложения гораздо труднее отлаживать, а значит и взламывать. При этом полезно усложнить взаимодействие между потоками, организуя его так, чтобы потоки выполняли часть логики приложения, и нельзя было их просто остановить или завершить.
5. Очень хорошим приемом являются «вероятностные» вызовы, когда функция API вызывается не всегда, а с какой-то вероятностью – например 1/7. В разных местах приложения можно использовать различные вероятности вызовов (причем в жизненно важных местах приложения вероятность может быть больше, в менее важных местах – меньше). В результате хакер может попросту не найти те вызовы, которые происходят с малой вероятностью – и тогда, якобы «взломанное», приложение рано или поздно преподнесет сюрприз нелегальным пользователям.
6. Усложните логику обработки кодов возврата функций API. Если вы будете проверять код возврата функции API простым сравнением, хакеру не составит труда уничтожить это сравнение прямо в теле приложения – и таким образом снять защиту. Разработайте более сложную логику. Например, используйте коды возврата в качестве индексов каких-то массивов данных, стартовых значений для генераторов псевдослучайных чисел, используйте их в алгоритмах математических вычислений, реализованных в приложении и т. п. Таким образом, точка, в которой защищенное приложение принимает решение о своей дальнейшей работе, в чистом виде будет отсутствовать. Хакеру придется разбираться не только в логике работы защиты, но и в хитросплетениях процессов, происходящих в самом приложении. И защита станет полноправной частью приложения, без которой станут неверными его вычисления, будут использоваться не те данные и т. д.
7. Откладывайте момент реакции приложения на коды возврата функций API. Хорошо зарекомендовал себя прием, когда приложение принимает решение о своей дальнейшей работе не сразу по получении кодов возврата функции API, а значительно позже. Например, функция API вызывается при запуске приложения, а анализ возвращенных ею значений производится при выполнении пользователем каких-либо действий (открытие или сохранение файла, вызов меню настройки приложения и т. п.). В таком случае хакеру будет сложно проследить причинно-следственную связь поведения приложения. Кроме того, этот прием заставит хакера исследовать в отладчике большие фрагменты кода приложения.
8. Ограничивайте возможности приложения, если электронный ключ не найден. Этот прием можно использовать в дополнение к описанному выше. Если функция API возвращает ошибку, можно не принимать кардинальных решений относительно дальнейшей работы приложения, а лишь ограничить его возможности. Например, перестать давать возможность экспортировать файлы в другие форматы, сохранять настройки, распечатывать отчеты и т. п. Причем, в ответ на неудачу при вызове API из разных мест приложения можно «лишать» его все новых и новых возможностей, все более превращая в демонстрационное. Помимо важных, можно блокировать и несколько второстепенных возможностей – это увеличит вероятность того, что хакер попросту не заметит их отсутствия, и приложение в таком виде попадет на «черный рынок». Пользователей же такой «демо-версии» отсутствие части ее возможностей подтолкнет на приобретение легальной копии приложения.
9. Подсчитывайте хэш важных участков кода приложения. Это мощное средство защиты от модификации хакером кода приложения. Предварительно вы подсчитываете хэш тех мест в программе, в которых производятся вызовы функций API, анализируются выходные данные функций и принимаются решения о дальнейшей работе приложения. В процессе работы приложения вы еще раз производите подсчет этих участков – и получаете достоверную информацию о том, были ли эти участки нелегально модифицированы. Производить подсчет хэшей лучше в отдельном потоке, причем делать это следует значительно раньше или значительно позже того, как управление попадет в контролируемый участок кода. Один и тот же участок целесообразно контролировать из нескольких мест приложения. А реакция на факт модификации программного кода должна быть примерно такой же, как и на ошибку при вызове функции API. В результате хакер будет вынужден дополнительно искать по всему телу приложения места, в которых вы проверяете контрольные суммы. Для вычисления хэш-функции можно воспользоваться функцией Guardant API GrdHash.
10. Меняйте логику работы приложения с модулями защиты. Очень полезно бывает время от времени (оптимальный вариант – в каждой новой версии защищенного продукта) менять логику его работы с модулями защиты. Используйте новые приемы, подобные описанным здесь, по-иному комбинируйте их и т. п. – и тогда при выходе новой версии продукта хакер будет вынужден начинать работу по ее исследованию, что называется, «с нуля». Все его прежние наработки мгновенно теряют актуальность – ведь теперь приложение взаимодействует с модулями защиты совершенно по-иному.
11. Используйте обфускаторы. Какой бы совершенный код защиты вы не написали, он почти всегда доступен хакеру для исследования посредством отладчиков, дизассемблеров. Есть специальные программы для затруднения анализа программ и понимания смысла того, что они делают. Их называют обфускаторами. Эти программы обрабатывают готовые приложения (exe-файлы) и модифицируют их таким образом, что стандартными средствами невозможно их понять, надо создавать специальные средства именно для данного обфускатора, а то и для данной защищенной программы (обфускаторы, как правило, полиморфны). Есть неплохие сторонние обфускаторы, которые можно использовать для этих целей. Дополнительно обфускаторы часто защищают приложения от изменения таким образом, что невозможно изменить в них даже один бит, сохранив работоспособность программы. Для взлома в таком случае приходится тоже создавать специальные инструменты, что долго и очень дорого.

Использование аппаратных алгоритмов ключей Guardant

Если вы остановили свой выбор на электронных ключах Guardant, в вашем распоряжении есть целый ряд эффективных приемов повышения стойкости защиты к взлому.
1. Задействуйте аппаратные алгоритмы. Это обязательное условие для построения по-настоящему стойкой защиты. Правильное использование ответов аппаратных алгоритмов не только делает практически невозможным написание универсальных эмуляторов ключей Guardant. Удаление из защищенного приложения вызовов функций API также теряет смысл – ведь если аппаратный алгоритм не был запущен, то и важные для приложения данные не были декодированы.
2. Задавайте ключу больше вопросов. Если для защиты используется преобразование только одного массива данных (т. е. если приложение задает ключу всегда один и тот же вопрос), есть вероятность, что хакер все же подсмотрит верный ответ ключа и создаст подпрограмму-«заглушку», которая вместо функции API «подсовывает» приложению этот ответ. Поскольку в данном случае ключ возвращает всегда один и тот же ответ, такая подпрограмма-«заглушка» может свести роль аппаратного алгоритма в защите данного приложения «на нет». Чтобы избежать этого, нужно задавать аппаратному алгоритму большое количество разных вопросов. Создайте массив различных вопросов (т. е. блоков кодированных данных), и в разных местах приложения декодируйте аппаратным алгоритмом разные кодированные блоки. Кстати, наряду с действительно важными для приложения данными в состав такого массива могут входить и «лишние» данные, на самом деле не нужные приложению – это только дезориентирует хакера. Очень хорошо было бы организовать процесс случайной выборки вопроса – тогда в одном и том же месте приложения, но в разные моменты времени будут обрабатываться разные вопросы. Это сделает практически невозможным для хакера создание, как подпрограммы-«заглушки», так и эмулятора ключа.
3. Используйте разные вопросы в разных версиях приложения. Если в разных приложениях или разных версиях одного и того же продукта будут использоваться разные вопросы к алгоритму (т. е. разные блоки кодированных данных), это даст гарантию того, что хакер не сможет создать универсальный инструмент для взлома всех продуктов (или всех их версий). Даже если хакер исхитрится-таки создать эмулятор для приложения, выход его новой версии заставит хакера производить свою работу заново – ведь новая версия приложения работает уже с другими кодированными данными.
4. Задействуйте разные аппаратные алгоритмы в разных версиях приложения. В электронном ключе создайте сразу несколько различных алгоритмов (например, 4). Затем, в первой версии программного продукта кодируйте данные, скажем, 1-м и 3-м алгоритмом, во второй – 2-м и 4-м, в третьей – 1-м и 2-м, и т. п. Эффект будет аналогичен рассмотренному выше, да и в самом электронном ключе ничего перепрограммировать будет не нужно – все необходимые аппаратные алгоритмы будут в нем присутствовать с самого начала.
5. Вносите изменения в определители алгоритмов. По своей сути определители алгоритмов аналогичны паролям или цифровым сертификатам, поэтому их тоже полезно время от времени менять. Это очень хорошая и распространенная во всем мире практика, повышающая защищенность системы. В ключах с часами реального времени полезно использовать для этого возможность автоматического изменения определителя каждые N дней. Алгоритм смены определителя подробно описан в документации, разработчику лишь остается подготовить массивы кодированных данных на несколько месяцев или лет вперед. Как и в предыдущих примерах, однажды взломанная программа может внезапно перестать работать т. к. определитель алгоритма сам изменился в какой-то момент времени.
6. Воспользуйтесь алгоритмом цифровой подписи. Алгоритм ECC160 позволяет подписывать произвольные данные с помощью функции GrdSign. Лучше всего, чтобы это были данные, которые возникают в приложении естественным образом (так называемая естественная энтропия): данные, которые пользователь вводит в программу с клавиатуры, движения мышки, значения из баз данных, полученные по запросу пользователя. Тогда простая табличная эмуляция станет невозможной. Проверять правильность подписи можно с помощью функции GrdVerifySign. Однако не следует использовать простое сравнения возвращаемого ею значения, т. к. сравнение по принципу «да/нет» легко сломать с помощью т. н. битхака (исправляется всего 1 бит в программе). Лучше всего собирать возвращаемые значения (например, из битов возврата GrdVerifySign делать 32-битные числа), проверять подпись случайных данных (создавать ложные цели для анализа хакером) и на основе большого числа вызовов GrdSign/ GrdVerifySign создавать значения, которые в дальнейшем можно использовать в работе защищенного приложения.
7. Не храните ответы аппаратных алгоритмов в защищенном приложении. Сам принцип использования аппаратных алгоритмов основан на предпосылке, что хакер не знает заранее ответов алгоритма. В противном случае алгоритмы не имеют особого смысла: хакер, зная все его ответы, может создать и эмулятор ключа, и подпрограмму-«заглушку». Поэтому ни в коем случае не следует хранить ответы ключа в приложении или в файлах данных! Просто используйте ответы ключа по назначению, без предварительной проверки правильности их декодирования алгоритмом, а сразу после использования – по возможности удаляйте из памяти. Данные могут быть декодированы неверно лишь в одном случае – если либо с защищенным приложением, либо с электронным ключом производились какие-то сомнительные манипуляции. Но, в таком случае, неверная работа (и даже «подвисание») приложения – событие весьма естественное. В самом деле, чего еще можно ожидать от приложения, «ломаемого» хакером, особенно если защита «надета» на приложение качественно? Но если проверка правильности ответов все же необходима, используйте для этого функцию подсчета CRC. На этапе установки защиты, перед тем как закодировать данные, вычислите их CRC, а в процессе работы приложения подсчитайте CRC этих же данных после их декодирования алгоритмом ключа. Если эти два значения совпали, то данные декодированы верно.
Важная информация
В связи с постоянно растущими вычислительными возможностями современных компьютеров настоятельно рекомендуется задавать размер вопроса/ответа и определителя аппаратных алгоритмов ключей Guardant не менее чем 8 байт. Это позволит минимизировать шансы атаки методом brute force (полный перебор).

Особенности использования ключей Guardant Sign / Time / Code

При работе с электронных ключами Guardant необходимо учитывать несколько важных особенностей, связанных с активным использованием ассиметричной криптографии, как в алгоритмах ключа, так и в защитных механизмах. Эти моменты необходимо учитывать при проектировании защиты.
1. Безопасный обмен сеансовыми ключами. При выполнении функции GrdLogin происходит взаимная аутентификация электронного ключа и Guardant API и безопасный обмен сеансовыми ключами. Слово «обмен» - это просто термин. На самом деле API и электронный ключ рассчитывают это значение независимо на основе безопасной ассиметричной схемы. В протоколе обмена его подсмотреть невозможно. Поэтому команда GrdLogin занимает существенно больше времени, чем остальные.
2. Периодическая смена сеансовых ключей. Если хакеру удастся как-то извлечь из защищенного псевдокодом Guardant API сеансовый ключ, то это тоже не принесет ему много пользы. Электронный ключ устроен так, что он работает на любом сеансовом ключе не больше нескольких минут. По его истечении, электронный ключ начинает возвращать специальный код ошибки в ответ на любую команду, полученную с использованием просроченного сеансового ключа, до тех пор, пока данная копия API опять не пройдет взаимную аутентификацию и не перегенерирует его заново. Соответственно, при проектировании защиты нужно учитывать тот факт, что эта перегенерация может занять какое-то дополнительное время. И если логика работы приложения не допускает таких задержек в выполнении, то лучше организовывать запросы к электронному ключу из параллельно работающих потоков.
3. Использование GrdSign и GrdVerifySign. Это очень мощный инструмент, который при правильном применении дает возможность создать защиту беспрецедентно высокого уровня. Для этого нужно во время работы защищенной программы аппаратно подписать (GrdSign) и программно проверить подпись (GrdVerifySign) от неких каждый раз разных случайных данных. Проверка подписи специально реализована чисто программно, так как это лишает хакера даже гипотетической возможности перехватить ее в эмуляторе на уровне драйвера или USB-шины. А ключ шифрования в ней используется публичный, который не может быть скомпрометирован.
4. Атака на генератор случайных чисел. Если хакер сможет сделать в электронный ключ запросы не случайными, а постоянными, то у него появится возможность сделать табличный эмулятор, который будет знать ответы на все вопросы, задаваемые программой. Чтобы посылаемые данные были действительно случайными, настоятельно рекомендуется использовать какой-либо хеш (например, SHA-256), от действительно случайных данных, которые использует программа и без которых она теряет смысл или львиную долю функциональности. Например, введенные пользователем данные, ID созданных потоков, адреса аллокированной памяти, и т. п. Иначе хакер сможет подсовывать приложению любые нужные ему значения в ответ на любые вызовы Guardant API.
5. Атака на подмену публичного ключа. Хотя публичный ключ ассиметричного алгоритма не является секретным, но, тем не менее, необходимо принять все меры по предотвращению его модификации и/или подмены.
a. Не хранить его просто инициализированным в сегменте данных (на Си это инициализированная глобальная или статическая переменная или константа), так как там его проще всего подменить
b. Рассчитывать его значение непосредственно перед использованием и сразу после использования затирать и удалять.
c. Контролировать целостность кода, который работает с ним.
6. Атака на подмену Guardant API. Чтобы хакер не мог просто заменить код функций Guardant API на свой эмулятор, необходимо:
a. Вызывать GrdVerifySign так, чтобы она в некой части возвратов возвращала другие коды ошибок, которые также надо проверять. Например, подавать на вход случайные данные в сообщении или подписи или неверный общий ECC ключ.
b. Среди этих вызовов очень полезно время от времени вызывать GrdVerifySign с запросом на проверку валидности подписи одного из валидных сообщений, подписанного на этом же ключе, но не в процессе работы программы, а на этапе защиты. Для этого при защите приложения в нем необходимо сохранить какое-то количество подписанных случайных сообщений с подписями. Аналогично тому, как это делается с различными массивами вопросов и ответов, используемыми при работе с симметричными алгоритмами.
c. Результат проверки подписи GrdVerifySign по сути один бит. Можно вместо того, чтобы ставить явную проверку кода возврата, составить из множества вызовов одну константу, которая будет использоваться в дальнейших вычислениях. Благо скорость работы подписи в ключе достаточно высока.
7. Использование однонаправленных симметричных алгоритмов шифрования AES и GSII64. Можно, например, сделать так, чтобы в электронном ключе для защиты приложения некий AES или GSII64 алгоритм работал в обоих направлениях, а в попадающем к конечным пользователям ключе он мог только расшифровывать. Тогда можно хранить в некой защищенной ячейке (или файле) какую-либо конфигурационную или лицензионную информацию, зашифрованную на этом алгоритме при продаже софта не боясь, что хакер сможет подменять ее. Ведь для подмены нужно записать в эту ячейку информацию, зашифрованную на этом алгоритме. А зашифровать ее на ключе пользователя, на этом же алгоритме хакер просто не сможет, из-за его однонаправленности. Аналогичные механизмы можно применять с распространением зашифрованных обновлений, которые хакер, имея ключ конечного пользователя с однонаправленным алгоритмом, не сможет зашифровать, модифицировать и подсунуть программе.
Важная информация
Однонаправленные алгоритмы AES128 можно использовать только в блочных режимах ECB и CBC. Поточные режимы CFB и OFB использовать нельзя.
8. Атака на замену GrdAPI.DLL. Обычно настоятельно рекомендуется всем нашим пользователям по возможности использовать статическую линковку, т. е. по сути, использовать Guardant API в виде OBJ вместо DLL. Если же это невозможно из-за ограничений средств разработки, то крайне рекомендуется сделать следующее:
a. Перенести часть функциональности во внешнюю DLL, к которой статически прилинкована библиотека Guardant API (OBJ).
b. Использовать традиционные механизмы работы с симметричными алгоритмами. Массивы вопросов и ответов, случайный выбор таблицы и запроса. Проверки при выполнении какой-либо функциональности.
c. Время от времени вызывать GrdVerifySign с запросом о проверке валидности подпись одного из валидных случайных сообщений, подписанного на этом же ключе, но не в процессе работы программы, а на этапе защиты. Если хакер даже перехватит все вызовы Guardant API, то он не будет знать, что вернуть на такой вопрос.
9. Time-ключи. Появилась возможность надежно задавать ограничение работы, как всего электронного ключа, так и любого конкретного алгоритма. Это дает возможность сдавать ПО в аренду. Однако рекомендуется уведомлять конечного пользователя о близости прекращения работа программы заранее, для того, чтобы он успел продлить лицензию до того, как программа перестанет работать. Для этого в Guardant API есть все необходимые функции типа GrdPI. См. документацию на Guardant API. Аналогичные опции предусмотрены в новом мастере автозащиты.
10. Счетчик запусков. Аналогично, в Sign-ключах появилась возможность получить оставшееся значение счетчика запусков алгоритма. Соответственно, о приближении его завершения нужно информировать конечного пользователя заранее. Для этого есть специальная функция типа GrdPI_. См. документацию на Guardant API. Эти же опции предусмотрены в новом мастере автозащиты.
11. Используйте драйвер Guardant. Хотя использования ключей в HID-режиме очень удобно для распространения защищенной программы, все же наличие драйвера Guardant увеличивает защищенность, и по возможности мы рекомендуем все же использовать ключи не в HID-режиме. Тем не менее, надо обратить внимание, что программа, защищенная ключами в HID-режиме, в любом случае обеспечивает защиту гораздо более высокую, чем предыдущие поколения электронных ключей.
12. Используйте Time-ключи не только для ограничения времени работы, но и для повышения уровня защищенности. В отличие от других типов Time-ключей, электронные ключи Guardant Time можно использовать для повышения уровня защищенности. Такая уникальная возможность как BirthTime позволяет создавать такие системы защиты, которые активируются спустя время и анализировать которые хакер никак не может заранее. А технология FlipTime позволяет создавать алгоритмы, определители которых меняются через заданное количество дней, что опять затруднит анализ защиты заранее. Утилита для генерации определителей FlipTime также включена в комплект разработчика вместе с исходным кодом.
13. Используйте высокую скорость работы новых ключей. Guardant Sign / Time / Code работают до 10 раз быстрее, чем их предшественники. Поэтому с их помощью можно шифровать и расшифровывать гораздо больше информации, и это не отразится на быстродействии защищенной программы.
14. Защита баз данных. Можно реализовать вариант защиты, при котором база данных шифруется с помощью программного AES. При продаже база комплектуется электронным ключом, содержащим аппаратный алгоритм AES с теми же параметрами, как у программного алгоритма, на котором база данных была зашифрована. Отличием алгоритма в электронном ключе будет то, что он работает только в режиме расшифрования (без зашифрования) и расшифровывает не всю базу данных, а некую ее часть, нужную пользователю. В этом случае, содержимое базы данных нельзя будет модифицировать.
Этот вариант подходит для случаев, когда у конечного пользователя нет необходимости пополнять базу данных.

Рекомендации по написанию загружаемого кода (Code)

1. Основная угроза для систем защиты, основанных на электронных ключах – это эмуляторы. Всегда существует шанс, что в результате анализа «черного ящика», которым является электронный ключ, злоумышленник сможет построить его эмулятор. Это может быть либо табличный эмулятор, либо универсальный эмулятор алгоритма.
При анализе черного ящика злоумышленник будет пытаться определить, каким образом изменения входных данных повлияют на выходные данные. Если этих днных мало, либо если алгоритм слишком простой, с высокой вероятностью можно построить алгоритм, функционально эквивалентный «черному ящику».
Поэтому алгоритм загружаемого кода должен быть нетривиальным и с достаточно большой сложностью. Он должен принимать на вход и давать на выход достаточно много данных.
2. Что делать, если функционально алгоритму требуется мало данных? Можно ввести дополнительные данные, не связанные напрямую с функциональностью алгоритма. По сути, это будут «мусорные» данные, однако их использование будет затруднять анализ «черного ящика». Аналитику придется разбираться, какие данные и для чего нужны, и нужны ли вообще.
3. Существует возможность неявного вызова аппаратных алгоритмов через загружаемый код. Например, можно возвращать данные из загружаемого кода зашифрованными на симметричном алгоритме AES128. Перед использованием они должны быть расшифрованы с использованием того же секретного ключа. Это увеличивает разнообразие данных, проходящих через интерфейс электронного ключа, и затрудняет эмуляцию. Для большего усложнения можно периодически менять ключ шифрования AES128 изнутри загружаемого кода.
4. Защищенные ячейки можно использовать для неявного обмена данными между загружаемым кодом и приложением. В них можно помещать как часть входных данных для загружаемого кода, так и принимать через них данные от загружаемого кода.
5. Загружаемый код должен контролировать данные, принимаемые от приложения, по размеру и корректности. Это поможет избегать определенного класса атак.
6. При возможности можно использовать сохранение данных в ключе между вызовами, так как размер таблицы вопросов-ответов в этом случае получается на порядок больше. Очевидно, такой подход сильно затруднит процесс построения эмуляторов.
7. Если в защищаемом приложении нет фрагментов со значительными вычислениями (только такие разумно размещать в Guardant Code), можно использовать идею трудности анализа большого количества простых множеств. Т.е. построить защиту на том, что размещаемые в ключе фрагменты небольшие, они делают простые вещи, но зато их много. Правда, это, по-прежнему, должны быть фрагменты, которые используются не слишком часто. Количество фрагментов должно быть действительно большим. Их точное количество зависит от сложности вычислений в них. Напримере, если во фрагментах только простые операции сложения или вычитания – их должно быть около пары сотен. Если есть умножение или деление – достаточно несколько десятков. Если функции типа логарифмов или синусов/косинусов, достаточно 10. Данные цифры действительны на ближайшие несколько лет (стойкость всегда оговаривается сроками).
8. Поскольку загрузка кода в Guardant Code – операция настолько безопасная, что может осуществляться у конечного пользователя, и быстрая даже для больших кусков загружаемого кода, можно создать защищенную программу, которую будет так же легко обновлять, как и незащищенную программу. Для этого не потребуется что-либо специальное делать с электронным ключом при обновлении – достаточно просто отправить клиенту обновление.
Более того, существует возможность даже не записывать в Guardant Code перед продажей загружаемый код! Это можно сделать в момент 1-го запуска программы, проанализировав значения, возвращаемые функцией GrdGetCodeInfo():

• Перед продажей программы записать в ключ маску без загружаемого кода
• В защищенной программе добавить проверку – загружен ли код в Guardant Code (точнее какой именно код загружен – существуют поля версии загруженного кода). Если кода нет, или он не тот, то загрузить его в момент инициализации приложения. Это произойдет только один раз при 1-м запуске программы. Поскольку загружаемый код зашифрован и подписан ЭЦП, в него невозможно внести изменений и невозможно подменить другим кодом или кодом от другой программы
• Поскольку бывают программы разной стоимости, и обновления тоже могут быть платными или бесплатными, нужно предусмотреть политику ограничения вариантов загрузки кода. То есть, надо сделать так, чтобы Update, предназначенный для дорогой программы, нельзя было загрузить в ключ, который был куплен для дешевой программы. Сделать это просто: ключи Guardant Code для разных программ должны иметь разные пары закрытых ключей для проверки ЭЦП загружаемого кода

Нужно обратить внимание, что контроль версии загружаемого кода самим ключом не осуществляется. Это может сделать только программа, которая загружает код. Поэтому данный метод не годится для платных обновлений, в отличие от бесплатных. Не годится потому, что обновление можно загрузить бесплатно в любой ключ, который содержит необходимые ключи шифрования и подписи для загрузки кода. Бесплатные обновления традиционно служат для исправления ошибок в ПО. Платные обновления применяются чаще всего тогда, когда пользователь программы получает новые возможности. Для платных обновлений надо пользоваться механизмом TRU, т. к. он настроен для работы с конкретным ключом и позволяет реализовать процедуру адресного обновления.