Что такое токен открытого ключа и как он рассчитывается в строгих именах сборок? - PullRequest
23 голосов
/ 21 февраля 2009

Что такое «токен открытого ключа» и как он рассчитывается в строгих именах сборки?

Ответы [ 6 ]

16 голосов
/ 21 февраля 2009

Что касается вашего вопроса "Как рассчитывается", то это хеш SHA1.

Из dot net blog :

Microsoft решает «открытый ключ» раздувать "проблема с помощью хэша открытый ключ со строгим именем сборки. Эти хеши называются публичными ключевые токены, и младшие 8 байтов хеш SHA1 со строгим именем открытый ключ сборки. SHA1 хэши 160 бит (20 байт) хэшей и верх 12 байтов хеша просто отбрасывается по этому алгоритму.

10 голосов
/ 08 марта 2012

Вы можете получить PublicKeyToken из командной строки VS, набрав:

sn –T DLLName.dll
6 голосов
/ 03 мая 2010

Если вам нужно сгенерировать токен открытого ключа на основе полного открытого ключа, этот небольшой статический метод работает:

   private static byte[] GetKeyTokenFromFullKey(byte[] fullKey)
    {
        SHA1CryptoServiceProvider csp = new SHA1CryptoServiceProvider();
        byte[] hash = csp.ComputeHash(fullKey);
        byte[] token = new byte[8];
        for (int i = 0; i < 8; i++ )
            token[i] = hash[hash.Length - (i+1)];

        return token;
    }
5 голосов
/ 21 февраля 2009

Из ECMA-335:

Эта декларация используется для хранения младших 8 байтов хэша SHA-1 отправителя. открытый ключ в ссылке на сборку, а не полный открытый ключ.
Ссылка на сборку может хранить либо полный открытый ключ, либо 8-байтовый «токен открытого ключа». Любой из них может использоваться для проверить, что тот же закрытый ключ, который использовался для подписи сборки во время компиляции, также подписывал сборку, используемую в во время выполнения. Ни то, ни другое не обязательно должно присутствовать, и хотя оба они могут быть сохранены, это бесполезно.

[Обоснование: открытый ключ или маркер открытого ключа, сохраненные в ссылке на сборку, используются для обеспечения того, чтобы сборка, на которую ссылаются, и сборка, фактически используемая во время выполнения, была произведена сущностью во владении одного и того же закрытого ключа, и поэтому можно предположить, что он предназначен для той же цели. В то время как Полный открытый ключ криптографически безопаснее, он требует больше места для хранения в ссылке. Использование открытого ключа Токен уменьшает пространство, необходимое для хранения ссылки, лишь слегка ослабляя процесс проверки. окончание]

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

Метаданные CLI позволяют производителю сборки вычислять криптографический хеш этой сборки (используя хэш-функция SHA-1), а затем шифровать ее с помощью алгоритма RSA (см. раздел I) и публичного / частного ключевая пара по выбору производителя. Результаты этого («цифровая подпись SHA-1 / RSA») могут быть сохранены в метаданных (§25.3.3) вместе с открытой частью пары ключей, требуемой алгоритмом RSA. Директива .publickey используется для указания открытого ключа, который использовался для вычисления подписи. Вычислять хеш, подпись обнуляется, хеш вычисляется, а затем результат сохраняется в подписи.

Процесс подписания строгого имени (SN) использует стандартные алгоритмы хеширования и шифрования для подписи строгого имени. SHA-1 хэш для большей части файла PE генерируется. Это хеш-значение подписано RSA с помощью закрытого ключа SN. За В целях проверки открытый ключ хранится в PE-файле, а также подписанное хеш-значение.
За исключением следующего, все части PE-файла хэшируются: • Подпись Authenticode: PE-файлы могут быть подписаны с помощью authenticode. Аутентикод подпись содержится в 8-байтовой записи со смещением 128 в каталоге данных заголовка PE («Таблица сертификатов» в §25.2.3.3) и содержимое PE-файла в диапазоне, определенном этим запись в каталоге. [Примечание: в соответствующем PE-файле эта запись должна быть нулевой. конечная нота] • Blob Strong Name: 8-байтовая запись со смещением 32 заголовка CLI («StrongNameSignature») в §25.3.3) и содержимое хеш-данных, содержащихся в этом RVA в файле PE. Если 8-байт запись 0, нет связанной строгой подписи. • Контрольная сумма заголовка PE: 4-байтовая запись со смещением 64 заголовка PE для Windows NT-Specific Поля («Контрольная сумма файла» в §25.2.3.2). [Примечание: в соответствующем PE-файле эта запись должна быть нулевой. конечная нота]

Вы можете скачать спецификацию здесь бесплатно: http://www.ecma -international.org / публикации / стандарты / Ecma-335.htm

3 голосов
/ 21 февраля 2009

Токен открытого ключа используется для идентификации организации в сборке со строгим именем. Эта информация добавляется в метабазу сборки. Я бы предположил, что Ричард прав насчет технического способа хранения.

Если вы хотите просмотреть метабазу сборки, используйте ILDASM. Вы можете углубиться в то, что хранится в метабазе в дополнение к просмотру IL.

0 голосов
/ 21 февраля 2009

Это хеш-байты ключа, используемого для подписи сборки.

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

...