Подписание и проверка автоматически сгенерированного отчета

Question

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

Моя немедленная реакция была: «Ну, мы должны подписать эти отчеты, чтобы подтвердить их подлинность». Решение, которое я задумал, заключалось в создании подписи для отчета, а затем встраивании его в метатег. К сожалению, этот сценарий потребует, чтобы приложение подписало отчет, а это значит, что ему потребуется закрытый ключ. Как только приложение сохранит закрытый ключ, мы вернемся на круги своя без гарантии подлинности.

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

Так что мой вопрос таков. Есть ли способ, кроме обфускации, проверить, действительно ли приложение сгенерировало данный отчет?

Answer 1

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

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

Answer 2

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

аутентификация отправителя:

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

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

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

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

аутентификация получателя:

Наличие пары ключей RSA 2048 на вашей принимающей стороне,Экспортируйте ваш открытый ключ отправителям.

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

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

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