Здравствуйте, _d_m_, Вы писали:
___>Допустим, есть одна сборка — .exe ___>CLR примет на исполнение?
___>...Это все понятно. Вопрос не в этом.
Если «всё понятно», то в чём же вопрос?
Вот у тебя есть строго подписанная сборка Sort.exe, которая сортирует массив. Я открываю Visual Studio, пишу на C# программу, выводящую на экран «Hello, world!», называю её тоже Sort.exe и не даю ей строгого имени (или даю другое). Затем я «модифицирую» исходную сборку Sort.exe, скопировав на её место свою Sort.exe. Такая «модификация» же не вызывает удивления? Не вызывает удивления, что подпись исходного файла не запрещает его подмену в файловом менеджере?
Во втором же предложении написана ерунда, даже две: «На основании сборки во время подписи вычисляется криптографический открытый ключ, закрытый хранится в секрете у производителя сборки, хеш-функция от которого и составляет public token...»
1) Пара ключей генерируется независимо от каких-то сборок. Грубо утрируя, прям в момент основания компании ООО «Вектор», отдел безопасности генерирует пару ключей, закрытый кладёт в сейф, открытый ключ (и опционально его токен) публикует на сайте.
2) Public key token — это хэш от открытого ключа.
___>Я так понял, строгое имя не защищает сборку от модификации, т.к. оно не обязательно.
То, что строгое имя можно просто вытереть из сборки — это совершенно естественно, закономерно, и никакое не открытие недели. Только это сломает загрузку сборки из других сборок. (Само по себе удаление строгого имени бесполезно, обычно оно рассматривается в контексте «дизассемблировать, изменить код, пересобрать, причём без строгого имени, так как всё равно не удастся подписать сборку от имени компании ООО „Вектор“, ведь не доступен их приватный ключ».) Чтобы это провернуть незаметно, мало модифицировать код сборки, нужно ещё построить транзитивное замыкание зависимостей, и изменить код (убрать подпись) всех сборок, зависящих от модифицированных в т.ч. косвенно (непрямо) для всех приложений и библиотек которые установлены или будут установлены на машине.
Скажем, если ты внедряешь злонамеренный код в сборку mscorlib.dll (соответственно, удаляя её строгое имя), то результатом будет лишь то, что все программы и библиотеки, использующие эту сборку сломаются, они не смогут её загрузить. Тебе придётся изменить весь вызывающий код, а также изменять новые приложения по мере их поступления на машину.
Вот, допустим, у тебя документ, заверенный нотариусом, о том, что тебе должны 1000 рублей. Ты отрезаешь в нём подпись (после этого вполне можешь дописать пару нулей) — действительно, тебе ж никто физически не запретит пользоваться ножницами, так же как и модифицировать байтики в dll'ках. Но тебе мало физически повлиять на этот документ, тебе ещё надо повлиять на всех, кто этот документ будет получать.
___>Я так понял, строгое имя не защищает сборку от модификации, т.к. оно не обязательно.
Строгое имя не защищает сборку от модификации в той же мере, что и аналоговая подпись не защищает от модификации ножницами и принтером официальный документ. Да, не защищает, но у тебя документ никто не примет. Или примет, если ты дашь принимающему взятку, а так же взятку принимающему у принимающего, etc.
Здравствуйте, _d_m_, Вы писали:
___>Я так понял, строгое имя не защищает сборку от модификации, т.к. оно не обязательно. ___>http://habrahabr.ru/blogs/net/91999/
Защищает настолько, насколько это возможно.
___>Возможно ли защитить сборку от модификации?
Если злоумышленник имеет физический доступ для модификации сборки и кода ее вызывающего — нет. Только обфускация, которая может затруднить осмысленное изменение.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, _d_m_, Вы писали:
___>>http://habrahabr.ru/blogs/net/91999/
Q>Во втором же предложении написана ерунда, даже две: «На основании сборки во время подписи вычисляется криптографический открытый ключ, закрытый хранится в секрете у производителя сборки, хеш-функция от которого и составляет public token...» Q>1) Пара ключей генерируется независимо от каких-то сборок. Грубо утрируя, прям в момент основания компании ООО «Вектор», отдел безопасности генерирует пару ключей, закрытый кладёт в сейф, открытый ключ (и опционально его токен) публикует на сайте. Q>2) Public key token — это хэш от открытого ключа.
Это все понятно. Вопрос не в этом.
Q>Строгое имя не защищает сборку от модификации в той же мере, что и аналоговая подпись не защищает от модификации ножницами и принтером официальный документ. Да, не защищает, но у тебя документ никто не примет. Или примет, если ты дашь принимающему взятку, а так же взятку принимающему у принимающего, etc.
Допустим, есть одна сборка — .exe
Не надо заигрываться аналогиями. CLR примет на исполнение? Примет. Какой еще принимающий, какие взятки?
Здравствуйте, Qbit86, Вы писали:
Q>Во втором же предложении написана ерунда, даже две: «На основании сборки во время подписи вычисляется криптографический открытый ключ, закрытый хранится в секрете у производителя сборки, хеш-функция от которого и составляет public token...» Q>1) Пара ключей генерируется независимо от каких-то сборок. Грубо утрируя, прям в момент основания компании ООО «Вектор», отдел безопасности генерирует пару ключей, закрытый кладёт в сейф, открытый ключ (и опционально его токен) публикует на сайте. Q>2) Public key token — это хэш от открытого ключа.
Ну и третье. Автор напирает на открывшуюся ему истину, что «Основная цель strong name или подписи сборки это ее уникальность в GAC (Global assembly cache)». Это не так. Строгое имя имело бы смысл даже если бы никакого GAC не существовало. Помимо прочего (версии, культуры), оно позволяет проверить издателя сборки; никто не может изменить сборку, сохранив её исходное авторство. Если изменён хоть байт, придётся удалять строгое имя или указывать при пересборке другое. Но этого нельзя сделать от имени того же издателя (не имея его приватного ключа).
Здравствуйте, Qbit86, Вы писали:
Q>Ну и третье. Автор напирает на открывшуюся ему истину, что «Основная цель strong name или подписи сборки это ее уникальность в GAC (Global assembly cache)». Это не так. Строгое имя имело бы смысл даже если бы никакого GAC не существовало. Помимо прочего (версии, культуры), оно позволяет проверить издателя сборки; никто не может изменить сборку, сохранив её исходное авторство. Если изменён хоть байт, придётся удалять строгое имя или указывать при пересборке другое. Но этого нельзя сделать от имени того же издателя (не имея его приватного ключа).
И ето тоже понятно. Еще могу добавить, что в CAS можно доверять всем сборкам подписанными определнным ключем.
