Проверка правильности серийного кода

Question

У меня есть метод в java, который генерирует серийный код на основе ряда параметров.

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

Возможно ли это?

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

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

methodICannotChange("someinput") returns serialcode 
methodICanInvent(serialcode, "someinput") returns true or false 

а ведьма «невозможно» генерировать новый серийный код при реализации метода methodananInvent.

Answer 1

Почему бы не сделать SerialCode объект? Передайте параметры в конструктор. Если параметры действительны, тогда создается объект SerialCode. Если нет, то конструктор терпит неудачу.

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

Вы можете предоставить SerialCodeFactory для создания этих объектов (см here для информации о заводах/фабричных методах), а не подвергать это к вашему клиенту, а только объекты SerialCode (через пакет обзорных или другие средства).

Answer 2

Безопасность вашего серийного кода не должна зависеть от знания алгоритма (т. Е. Иметь неизвестный алгоритм) и «общедоступных» входных параметров.

Это должно зависеть только от секретного держал под замком:

serialNumber(input parameters, secret) -> serial number 

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

Защитные хеш-функции предназначены для удовлетворения ваших требований.

serialNumber(parameters, secret) = md5(parameters & secret) 
verify(parameters, secret, serialNumber) = md5(parameters & secret) == serialNumber 

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

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

Answer 3

Что вы делаете, это в основном создание пользовательских hash function. Функция хеширования позволяет отвечать только в том случае, если заданные данные соответствуют совпадающим данным с входными данными. То есть любой может создать дайджест для данных.

Что вы действительно хотите, это digital signature. То есть общая идея состоит в том, чтобы сделать следующее:

1. Создание частных и открытых ключей;
2. Вывести открытый ключ любому клиенту;
3. Создать дайджест для данных и подписать с личным ключом любые данные следует доставить клиенту;
4. Клиент расшифровывает зашифрованное сообщение переваривать с помощью открытого ключа, вычисляет дайджест сообщения для приведенных данных и проверяют, что рассчитывается дайджест такого же, как поставки;

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

Answer 4

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

Вы можете только усложнить жизнь для них:

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

Answer 5

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

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

В клиентском коде ключ цифровой подписи/серийный может быть проверен с использованием только данных параметров и самого серийного ключа. Конечно, вы должны создать общедоступный и prvate-ключ. Открытый ключ должен быть включен в код, который выставляется клиентам. Частный ключ должен быть в безопасности.

Есть классы, которые помогают создавать цифровые подписи. Look here for a tutorial.

Answer 6

Учитывая, что вы не можете изменить генерацию серийного кода на использование асимметричной криптографии, я бы переместил проверку на веб-службу. Поэтому methodICanInvent (serialcode, someinput) вызывает веб-службу, выполняющую проверку, и возвращает true или false.

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