Я не могу понять эту вещь подписания сборки .NET

Question

Хорошо, я должен быть глуп, потому что я уже читал это: http://www.csharp411.com/net-assembly-faq-part-3-strong-names-and-signing/

И я до сих пор не понимаю ...

Допустим, я открываю свойства своего проекта и перехожу на вкладку «Подписывание», затем проверяю «Подписать сборку» и генерирую новую сборку с паролем. Был создан файл ключа строгого имени с расширением .pfx, с открытым и закрытым ключами, и VS будет подписывать мою сборку при сборке, верно?

А как насчет закрытого ключа? Не должно ли быть частным, и я, разработчик, должен быть единственным? Разве сборка не должна быть подписана только открытым ключом?

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

Answer 1

Вы в основном правы.

Вы создаете пару ключей и используете ее для подписи. Но не отправляйте файл pfx (или snk), он содержит как открытый, так и закрытый ключи и должен храниться в безопасности.

Открытый ключ добавляется в сборку как часть процесса подписи.

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

И все это так же надежно, как и ваша способность хранить файл ключа в секрете.

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

Answer 2

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

Answer 3

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

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

Answer 4

Подпись = Шифрование SHA1-хэша сборки с помощью закрытого ключа
Проверка = Сравнение дешифрованной подписи PublicKey с вычисленным хешем сборки

Таким образом, любой пользователь с PublicKey может проверить сборку, но только Автор с PrivateKey может подписать сборку.

PublicKey token = последние 64 бита SHA1-хеша PublicKey в порядке байтов с прямым порядком байтов.