Когда вы подписываете сборку строгим именем на основе созданного вами закрытого ключа, это дает следующие преимущества:
- Строгое имя гарантирует уникальность идентичности сборки, добавляя к сборке токен открытого ключа и цифровую подпись.
- Строгое имя можно сопоставить с открытым ключом, чтобы доказать, что сборка исходит от издателя с этим открытым ключом и только от этого издателя.
- Строгое имя обеспечивает строгую проверку целостности. Прохождение проверок безопасности .NET Framework гарантирует, что содержимое сборки не изменилось с момента ее последней сборки.
Можно ли использовать строгое именование для проверки автора сборки?
Да, как обсуждалось выше, строгое именование позволяет проверить последнего автора сборки. Но это не подтверждает подлинного автора. Если злоумышленник заменяет строгое имя вашей сборки, то все, что можно проверить, - это то, что вы не были последним автором сборки. Если он удалит строгое имя, проверка автора будет невозможна.
В какой степени можно проверить сборку со строгим именем, чтобы избежать подделки?
Следующий код C # проверяет, что злоумышленник не подделал токен открытого ключа, который был записан в вашу сборку, когда вы применили строгое имя. Он не защищает от взлома, но может обнаруживать некоторые типы взлома. Приведенный ниже метод принимает массив байтов, содержащий ваш токен открытого ключа, и сравнивает его с фактическим токеном сборки. Обратите внимание, что для того, чтобы этот метод был эффективным, выбранный вами обфускатор должен зашифровать строку, содержащую ваш токен открытого ключа, и расшифровывать ее только на лету, когда она используется. Также имейте в виду, что вам необходимо иметь разрешение FullTrust для работы этого кода, потому что он использует отражение под капотом.
// Check that public key token matches what's expected.
private static bool IsPublicTokenOkay_Check(byte [] tokenExpected)
{
// Retrieve token from current assembly
byte [] tokenCurrent = Assembly.GetExecutingAssembly().GetName().GetPublicKeyToken();
// Check that lengths match
if (tokenExpected.Length == tokenCurrent.Length)
{
// Check that token contents match
for (int i = 0; i < tokenCurrent.Length; i++)
if (tokenExpected[i] != tokenCurrent[i])
return false;
}
else
{
return false;
}
return true;
}
Если вы работаете с версией .NET Framework до .NET 3.5 SP1, вы также можете принудительно проверить подпись строгого имени в случае, если сильное имя было удалено злоумышленником или проверка строгого имени была отключена в реестр. Следующий код демонстрирует вызов статического метода другого класса с именем NativeMethods. Здесь проверка будет принудительной.
// Check that this assembly has a strong name.
private bool IsStrongNameValid_Check()
{
byte wasVerified = Convert.ToByte(false);
byte forceVerification = Convert.ToByte(true);
string assemblyName = AppDomain.CurrentDomain.BaseDirectory +
AppDomain.CurrentDomain.FriendlyName;
return NativeMethods.CheckSignature(assemblyName,
forceVerification,
ref wasVerified);
}
Фактическая проверка подписи выполняется с помощью P / Invoke, как показано ниже. Использование API StrongNameSignatureVerificationEx довольно запутано - достойное объяснение см. В эту запись в блоге.
// P/Invoke to check various security settings
// Using byte for arguments rather than bool,
// because bool won't work on 64-bit Windows!
[DllImport("mscoree.dll", CharSet=CharSet.Unicode)]
private static extern bool StrongNameSignatureVerificationEx(string wszFilePath,
byte fForceVerification,
ref byte pfWasVerified);
// Private constructor because this type has no non-static members
private NativeMethods()
{
}
public static bool CheckSignature(string assemblyName,
byte forceVerification,
ref byte wasVerified)
{
return StrongNameSignatureVerificationEx(assemblyName,
forceVerification,
ref wasVerified );
}
Обратите внимание, что это не будет работать по умолчанию для приложений, использующих .NET 3.5 SP1 или выше, у которых есть функция обхода строгого имени. Эту функцию можно отключить для вашего приложения, добавив параметр в его файл конфигурации. Но, конечно, любой злоумышленник с доступом для чтения / записи к этому файлу конфигурации может изменить ваше решение.
person
HTTP 410
schedule
15.12.2008
