Перепутанный шифрованием с открытыми и закрытыми ключами (чтобы использовать для шифрования),

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

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

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

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

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

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

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

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

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

Тогда возникает вопрос, как сделать безопасную систему DRM? Если вы используете шифрование и даете получателям закрытый ключ, они могут распространять либо ключ, либо расшифрованный контент. Если вы используете подписи, они могут просто удалить часть вашей программы, связанную с проверкой подписи".

Ответ заключается в том, что это невозможно. Концепция DRM в корне ошибочна.

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

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

На практике симметрия не так однозначна; различные режимы работы имеют разные слабости и проблемы, поэтому реализация обычно существенно отличается, но общая идея такова.

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

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