Файл Snk и задержка подписи

Я работаю с набором сборок с отложенной подписью, которые я могу установить и загрузить из GAC после пропуска проверки (sn -Vr * ...

Поскольку для Delaysigning как процесса требуется только файл открытого ключа

  1. sn -k keys.snk (как открытый, так и закрытый ключи)
  2. sn -p keys.snk pkey.snk (только открытый ключ)
  3. Добавьте pkey.snk в свойства проекта и установите флажок «Только задержка подписи».
  4. sn -v (отображает сборку с отложенной подписью)
  5. sn -e (извлечь pkey)
  6. fc (различий не найдено)

Я обнаружил, что первые 160 байт файла SNK - это PKey ... а остальные 436 байт представляют собой закрытый ключ.

Хотя для целей разработки должно быть достаточно sn-Vr или sn -R keys.snk (новая пара открытого / закрытого ключей для замены одной отложенной подписи), мне любопытно узнать, нужно ли извлекать открытый ключ из сборки и связывать его с вашим собственным закрытым ключом будет работать ...

Это может быть потенциальная лазейка в безопасности (поскольку сборки просматриваются с помощью токенов открытого ключа) ... Неудивительно, что в .Net framework / SDK нет встроенного инструмента, который позволяет это.

Есть ли место, где документируется вся файловая структура (формат файла) SNK? Может ли такой подход вообще работать? Что вы думаете?


.net sn.exe snk
person Vyas Bharghava    schedule 23.12.2009    source источник
comment
Что такое дыра в безопасности? Ваше описание неясно.   -  person SLaks    schedule 23.12.2009
comment
Я сказал потенциал ... Не эксперт ... В верхней части моей головы: вы можете притвориться, что чей-то открытый ключ принадлежит вам ... И ваши токены открытого ключа будут совпадать ... Если бы мне были назначены права безопасности / проверка была пропущена на основе на токене открытого ключа вы потенциально можете воспользоваться ...   -  person Vyas Bharghava    schedule 23.12.2009

Ответы (1)


arrow_upward
1
arrow_downward

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

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

Дополнительную информацию см. здесь.

person SLaks    schedule 23.12.2009
comment
@SLaks: Спасибо за ответ ... Ну, это не секретный вопрос :) Или, по крайней мере, он не был предназначен ... Вам нужен только «открытый ключ», чтобы отложить подписку ... У меня нет доступа к производственному закрытому ключу ... Чтобы я даже загрузил сборку с отложенной подписью, мне нужно пропустить проверку и прочее ... Мне просто интересно, могу ли я повторно подписать сборку, используя файл SNK, который имеет выпуск открытый ключ и мой собственный домашний закрытый ключ ... Другими словами, я ищу способы заменить открытый ключ в файле SNK, который имеет оба ключа ... - person Vyas Bharghava; 23.12.2009
comment
@SLaks: Это верно, когда вы напрямую подписываете ... Потому что компилятор вычисляет хэши с вашим закрытым ключом ... Не когда вы откладываете подписание ... Вам не нужен закрытый ключ ... Кроме того, sn имеет возможность пересчитывать хеши sn -Ра ... Я так понимаю, ведь хеши в сборке тоже можно было заменить на новые. - person Vyas Bharghava; 23.12.2009
comment
Как я думал, я объяснил, нет. Вы не можете так смешивать и сочетать ключевые части. - person SLaks; 23.12.2009
comment
Если вы спрашиваете, можете ли вы повторно подписать сборку с помощью производственного закрытого ключа, да, можете. - person SLaks; 23.12.2009