Безопасно скрывать закрытый ключ RSA позади #if отладки?

Question

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

Я сделал класс лицензии, который подписан с использованием RSA. Проверка подписи выполняется с использованием открытого ключа, создавая подпись с использованием закрытого ключа. Поскольку я сам создаю лицензии, сам код подписи/создания не должен находиться в самом классе лицензии (выпущенном коде). Но, с другой стороны, я хотел бы иметь весь код класса и не писать код подписания/создания лицензии в частичном классе, который даже является частью другого проекта (приложение локального менеджера лицензий). Безопасно ли сделать что-то вроде следующего:

public class License { 
    private const string publicRSA = "whatever"; 

    #if DEBUG 

    public void CreateLicense() 
    { 
     string privateRSA = "whatever again"; 

     // Do license creation stuff below... 

    } 

    #endif 

    // Other license code follows below.... 

} 

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

Я что-то упустил (относительно поведения прекомпилятора в C# ...)? Помимо выпуска случайно отладочной версии, могу ли я выстрелить себе в ногу, сделав это? Есть ли лучшие варианты?

Answer 1

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

Когда компилятор C# встречается с директивой #if, а затем в конце концов директивой #endif, он будет компилировать код между директивами только в том случае, если указан указанный символ.

https://msdn.microsoft.com/en-us/library/4y6tbswk.aspx

Однако, мы не знаем, какой вид оптимизации компилятора или Visual Studio можно использовать при строительстве, и поэтому он может скомпилировать код RSA в некоторых других временных файлов для кэширования или любой другой, даже если выпущенный код не содержит указанный код.

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

https://www.asp.net/identity/overview/features-api/best-practices-for-deploying-passwords-and-other-sensitive-data-to-aspnet-and-azure