Подписание сборок .NET

Question

Я пытаюсь понять формальное подписание .NET dll / сборок.

В частности

• Когда и как использовать закрытые ключи
• Лучшие практики для создания / контроля личных ключей
• Какие модули должны быть подписаны / лучшие практики для этого

Answer 1

См. Использование Строгое имя подписи , где приведена очень хорошая статья о подписи.

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

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

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

Answer 2

1. Когда вы хотите, чтобы ваши потребители знали, что сборки действительно от вас (а не самозванца)
2. Закрытые ключи для организации / организации должны быть доступны только избранным и храниться под замком. Используйте отсрочку во время разработки.
3. В идеале вы должны подписать все свои управляемые сборки.

Answer 3

Не путайте подпись строгого имени с подпись Authenticode

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

Я не уверен на 100%, но сборки Mono System соответствуют открытому ключу Microsoft. Не совсем форма безопасности .............

Вместо этого используется подпись Authenticode для проверки подлинности кода. Вам нужен платный сертификат от доверенного центра сертификации и подписать свои сборки с помощью signtool.exe или Visual Studio.

Все, что здесь сказано о безопасности, серверах подписи и т. Д., Применимо и здесь. Но дело в том, что вы не указали, какую подпись вы хотите вставить в код.

Answer 4

* When and how to use private keys
* Best practices for creation/control of private keys

Вы создаете и используете пару ключей (file.SNK).Создавайте его только один раз (для вашей компании / отдела) и сохраняйте его в безопасности.

* What sort of modules need to be signed/ best practice for going about it

Вам нужно , чтобы подписать библиотеки, которые входят в GAC.Но лучше всего подписывать все сборки, которые вы отправляете.

Когда надежность этой подписи очень важна, вы используете «Частичное подписание» и окончательное подписание непосредственно перед отправкой.Это означает, что не каждому разработчику необходим доступ к (реальной / полной) ключевой паре.

Answer 5

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

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

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