Поздно здесь игра ...
Подход хранения ключей в конфигурации сборки / сборки принципиально небезопасен. Не существует никакого железного способа сохранить его, поскольку определенный пользователь будет иметь доступ. Мне все равно, если вы используете лучший / самый дорогой продукт для запутывания на планете. Мне все равно, если вы используете PDAPI для защиты данных (хотя это лучше). Мне все равно, если вы используете локальное хранилище ключей, защищенных ОС (это еще лучше). Ни один из них не идеален, поскольку все страдают от одной и той же основной проблемы: у пользователя есть доступ к ключам, и они там, неизменяясь в течение дней, недель, возможно, даже месяцев и лет.
Гораздо более безопасным подходом было бы обеспечить безопасность вызовов API с помощью проверенной и настоящей PKI. Тем не менее, это приводит к очевидным перегрузкам производительности, если ваши вызовы API болтливы, но для подавляющего большинства приложений это не проблема.
Если производительность является проблемой, вы можете использовать Диффи-Хеллмана поверх асимметричной PKI, чтобы установить общий секретный симметричный ключ для использования с шифром, таким как AES. «общий» в данном случае означает общий доступ между клиентом и сервером, а не всеми клиентами / пользователями. Нет жестко закодированного / запеченного в ключе. Anywhere.
Ключи преходящи, регенерируются каждый раз, когда пользователь запускает программу, или, если вы действительно параноик, они могут прерваться и потребовать отдыха.
Сами вычисленные общие секретные симметричные ключи хранятся только в памяти, в SecureString. Их трудно извлечь, и даже если вы это сделаете, они хороши только в течение очень короткого времени и только для связи между этим конкретным клиентом (то есть тем сеансом). Другими словами, даже если кто-то взломает их локальные ключи, они хороши только для вмешательства в местное общение. Они не могут использовать эти знания для воздействия на других пользователей, в отличие от встроенного ключа, который используется всеми пользователями через код / конфигурацию.
Кроме того, сами ключи никогда не передаются по сети. Клиент Алиса и сервер Боб самостоятельно вычисляют их. Те сведения, которые они передают, чтобы сделать это, теоретически могут быть перехвачены Чарли третьей стороной, что позволит ему самостоятельно рассчитать общий секретный ключ. Вот почему вы используете эту (значительно более дорогую) асимметричную PKI для защиты генерации ключей между Алисой и Бобом.
В этих системах генерация ключей довольно часто связана с аутентификацией и, следовательно, созданием сеанса. Вы «входите в систему» и создаете свой «сеанс» через PKI, и после этого клиент и сервер независимо имеют симметричный ключ, который можно использовать для более быстрого на порядок шифрования для всей последующей связи в этом сеансе. Для крупномасштабных серверов важно сэкономить циклы вычислений при расшифровке, используя, скажем, TLS для всего.
Но подождите: мы еще не в безопасности. Мы только запретили читать сообщения.
Обратите внимание, что по-прежнему необходимо использовать механизм дайджеста сообщений для предотвращения манипуляций с человеком посредине. Хотя никто не может прочитать передаваемые данные, без MD нет ничего, что могло бы помешать им изменить его. Таким образом, вы хешируете сообщение перед шифрованием, а затем отправляете хеш вместе с сообщением. Затем сервер повторно хэширует полезную нагрузку после дешифрования и проверяет, соответствует ли она хэшу, который был частью сообщения. Если сообщение было изменено в пути, оно не будет изменено, и все сообщение будет отклонено / проигнорировано.
Последний механизм, необходимый для защиты - это повторные атаки. На данный момент вы запретили людям читать ваши данные, а также изменять ваши данные, но вы не препятствовали тому, чтобы они просто отправляли их снова. Если это проблема для вашего приложения, его протокол должен предоставлять данные, а клиент и сервер должны иметь достаточно информации о состоянии для обнаружения воспроизведения. Это может быть что-то такое же простое, как счетчик, который является частью зашифрованной полезной нагрузки. Обратите внимание, что если вы используете транспорт, такой как UDP, у вас, вероятно, уже есть механизм для работы с дублированными пакетами, и, следовательно, вы уже можете бороться с атаками воспроизведения.
Что должно быть очевидно, так это понять, что это нелегко. Таким образом, используйте PKI, если вы АБСОЛЮТНО не можете.
Обратите внимание, что этот подход интенсивно используется в игровой индустрии, где крайне желательно тратить как можно меньше вычислений на каждого игрока для достижения более высокой масштабируемости, в то же время обеспечивая защиту от взлома / любопытных глаз.
Итак, в заключение, если это действительно то, что вызывает беспокойство, вместо того, чтобы пытаться найти надежное хранилище ключей API, не делайте этого. Вместо этого измените то, как ваше приложение использует этот API (естественно, если вы имеете контроль над обеими сторонами). Используйте PKI или симметричный гибрид с общим PKI, если PKI будет слишком медленным (что в наши дни является проблемой). Тогда у вас не будет храниться ничего, что представляет собой проблему безопасности.