Может строгое именование блок использоваться для проверки автора блока?

20
задан Community 23 May 2017 в 12:02
поделиться

3 ответа

При подписании блока со строгим именем на основе закрытого ключа, который Вы создаете, это обладает следующими преимуществами:

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

это возможный использовать строгое именование для проверки автора блока?

Да, как обсуждено выше строгого именования может проверить блок последний автор. Но это не проверяет исходного автора. Если взломщик заменяет строгое имя Вашего блока, то все, что может быть проверено, - то, что Вы не были последним автором блока. Если он удаляет строгое имя, то никакая проверка автора не может быть сделана вообще.

, К которой степени сборка со строгим именем может быть проверена, чтобы не вмешиваться?

следующий код C# проверяет, что взломщик не вмешался в маркер открытых ключей, который был записан в Ваш блок, когда Вы применили строгое имя. Это не старается не вмешиваться, но это может обнаружить некоторые типы вмешательства. Метод ниже принимает массив байтов, содержащий Ваш маркер открытых ключей, и сравнивает его с фактическим маркером блока. Обратите внимание, что, чтобы эта техника была эффективной, Ваше obfuscator предпочтительное должно зашифровать строку, содержащую Ваш маркер открытых ключей, и только дешифровать ее на лету, поскольку она используется. И также знайте, что у Вас должно быть разрешение 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 перед.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 как показано ниже. Использование StrongNameSignatureVerificationEx API является довольно замысловатым - для достойного объяснения, см. эта запись в блоге .

// 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 или выше, который имеет функция обхода строгого имени . Это возможно к , отключают эту опцию для Вашего приложения путем добавления установки на ее файл конфигурации. Но конечно любой взломщик с доступом для чтения-записи к тому файлу конфигурации может инвертировать Ваше решение.

22
ответ дан 30 November 2019 в 00:14
поделиться

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

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

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

12
ответ дан 30 November 2019 в 00:14
поделиться

Я думаю, что строгие имена полезны для управления версиями и могут использоваться для помощи с установкой доверительных уровней для Безопасности доступа к коду Редактирование : <забастовка>, но Вы не можете использовать их, чтобы проверить, что блок создается кем-то, доверял или определенным автором. Видят комментарий от @RoadWarrior и ответ @RoadWarrior на этот вопрос.

Строгое именование Ваш блок не делает это защищенным от несанкционированного использования.
Редактирование: См. комментарии от @RoadWarrior и @divo. Если Ваше приложение проверяет исходный закрытый ключ от автора блока и вызывает проверку строгого имени, мой оператор является неправильным. Если однако у взломщика есть доступ к весь блоки в Вашем приложении, и/или Вы используете из проверки строгого имени поля в соответствии с лишенным CLR затем, я поддерживаю то, что я сказал.

Это может ниспровергаться решительный взломщик .

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

1
ответ дан 30 November 2019 в 00:14
поделиться
Другие вопросы по тегам:

Похожие вопросы: