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

Question

Я создаю систему лицензирования, когда клиенты запрашивают лицензию на моем сервере, и я отправляю им лицензию, если им разрешено иметь ее.

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

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

В таком случае, что я должен делать?

Answer 1

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

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

В таком случае, что мне делать?

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

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