Лучшее место для скрытия ключа в реестре Windows?

Моя программа Delphi имеет встроенный механизм защиты для проверки запрещенных лицензионных ключей в Интернете и отображает сообщение пользователю, если найден черный ключ.

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

Каков наилучший способ скрыть обфускацию записи в реестре Windows?

Спасибо!

Редактирование: у вас, ребята, есть хорошие ответы, но я чувствую, что мне нужно расширить вопрос.

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

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

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

Таким образом, я думаю, было бы лучше скрыть это в реестре. Мои пользователи недостаточно технически, чтобы использовать инструменты реестра для мониторинга реестра, но если я поместил его под HKLM/Software/MyCompany/MyProgram, некоторые из них могли бы найти его. Поэтому мне нужно место, где они не могут найти после этого, что он был создан. (Никто не ожидает этого!)

Любые идеи?

Ответы

Ответ 1

Самый простой способ скрыть ключ или значение - создать ключ/значение, имеющее '\ 0' внутри имени. Вы можете сделать это с учетом собственных функций NtCreateKey (см. http://msdn.microsoft.com/en-us/library/ff556468.aspx) NtSetValueKey (см. http://msdn.microsoft.com/en-us/library/ff557688.aspx), которые используют UNICODE_STRING как параметры вместо LPCTSTR. Вы можете больше узнать об использовании собственного API-интерфейса реестра в http://www.codeproject.com/kb/system/NtRegistry.aspx. Код Delphi вы найдете здесь http://www.delphi3000.com/articles/article_3539.asp.

ОБНОВЛЕНО. Поскольку многие люди читают этот вопрос, я хочу добавить несколько слов в свой ответ. Я хочу разделить часть вопроса, которую мы можем прочитать в заголовке "лучшее место, чтобы скрыть ключ в реестре Windows" от темы с лицензионными ключами. Поскольку я прочитал некоторые ответы (передо мной), которые касались почти только части лицензионных ключей и практически не отвечали на вопрос из названия, я написал мне ответ.

Объект с лицензионным ключом я нахожу очень сложным. Это зависит от выбранной модели лицензирования. Это важно, как создавать, распространять (устанавливать) и проверять ключ. Ключ должен быть зависит от аппаратного обеспечения или нет? Он может быть один на компьютер или один на группу компьютеров. Генерация ключа, установка ключа или проверка ключа могут быть либо в отношении некоторых онлайн-сервисов (также из Интернета), либо без них. Я могу продолжить... Есть много аспектов, преимуществ и недостатков различных подходов.

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

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

  • Программное обеспечение, установленное на клиентском компьютере, нуждается в активации. Перед активацией он не может работать или работать в очень ограниченной форме (например, включены только некоторые меню, необходимые для активации программного обеспечения).
  • Вы пишете серверный компонент, который будет использоваться клиентом во время активации для генерации лицензионного ключа на основе запроса активации, полученного от клиента.
  • Если клиент оплачивает программное обеспечение, вы включаете информацию о "идентификаторе машины" клиента (в любой форме, которая вам нужна) в базе данных на сервере.
  • После запуска процесса активации с клиентского программного обеспечения (либо в начале программы из меню, либо любым другим способом, как вы хотите), он собирает некоторую информацию о компьютере, таком как имя компьютера ( "идентификатор машины" ), некоторые серийные номера или другую информацию об оборудовании или операционной системе, которые не могут быть изменены без новой активации. Эта информация отправляет программное обеспечение на ваш сервер (это запрос активации).
  • Сервер проверяет, что клиент с "идентификатором машины" заплатил за программное обеспечение и еще не активирован. Затем сервер вычисляет хеш (SHA1, MD5 или какой-либо другой) из информации, отправляемой от клиента, и подписывает ответ с помощью секретного ключа сервера (или сертификата сервера). Подписанный билетный сервер будет отправлен обратно клиенту. Этот билет будет играть роль лицензионного ключа.
  • Сервер может добавлять дополнительную информацию в билет до подписания. Например, он может добавить информацию о дате до того, как программное обеспечение будет действительным (например, текущий день плюс один год). Таким образом, билет, который будет отправлен обратно клиенту, может содержать хэш информации активации ввода и любую дополнительную информацию, все, что вы хотите. Важно только то, что информация должна быть подписана. В общем случае вы можете включить полный запрос клиента как чистый текст в билете серверов вместо включения хеша, но использование хэша a) уменьшить размер билета и b) сделать билет немного более безопасным.
  • Каждый клиент имеет открытый ключ, соответствующий закрытому ключу, используемому сервером для подписания активационного билета. Клиент сохраняет билет, полученный от сервера, во время активации в любом месте в реестре в файловой системе.
  • В следующий раз, когда клиентское программное обеспечение будет запущено, программное обеспечение будет считывать сохраненный билет активации из реестра (или из файловой системы). Затем программное обеспечение собирает ту же информацию, которая используется для генерации билета активации, вычисляет хэш и сравнивает его с хешем из сохраненного билета. Он проверяет причину подписания билета в отношении открытого ключа (или в отношении сертификата сервера). Кроме того, программное обеспечение может проверять любую другую дополнительную информацию о политике из билета, например, время, пока билет не будет действительным.

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

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

Ответ 2

Я не думаю, что реестр является хорошим местом для скрытия такой информации, потому что любой может загрузить и использовать Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) и посмотреть, что ваша программа делает с реестром.

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

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

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

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

Ответ 3

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

Обязательно проверьте, есть ли в реестре какие-либо ключи, если пользователь не удалил их.

Ответ 4

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

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

Я бы предложил второй подход для вас.

Ответ 5

Обратите внимание, что существуют обычные инструменты конечного пользователя, которые контролируют, какие приложения записывают в реестр (например, Cleansweep). Это касается уровня API-интерфейса, поэтому он, вероятно, поймает обходные пути # 0.

Вы можете попытаться зашифровать весь shebang в ключе реестра, с чем-то, что однозначно идентифицирует машину (например, MAC-адрес) и временную метку, чтобы люди не могли переместить ключ на другие компьютеры. THEN всегда требует наличия такого ключа для запуска и требует подключения к Интернету для обновлений/активации, если его там нет. (или временная метка очень старая)