Защита памяти приложения от взлома

Мы добавляем 256-битное шифрование AES в наши серверные и клиентские приложения для шифрования трафика TCP / IP, содержащего конфиденциальную информацию. Мы будем менять ключи ежедневно. Из-за этого ключи будут храниться в памяти вместе с приложениями.

Процесс распределения ключей:

  1. Каждый сервер и клиент будут иметь список начальных ключей шифрования ключей (KEK) по дням.

  2. Если клиент только что запустился или сервер только что запустился, клиент запросит у сервера ежедневный ключ, используя начальный ключ. Сервер ответит ежедневным ключом, зашифрованным начальным ключом. Ежедневный ключ - это случайно сгенерированный набор буквенно-цифровых символов. Мы используем 256-битное шифрование AES.

  3. Все последующие сообщения будут зашифрованы с использованием этого ежедневного ключа.

  4. Каждую ночь клиент будет запрашивать у сервера новый дневной ключ, используя текущий дневной ключ в качестве текущего KEK. После того, как клиент получит новый ключ, новый ежедневный ключ заменит старый ежедневный ключ.

Может ли другое плохое приложение незаконно получить доступ к этой памяти или это защищено в Windows? Ключ не будет записан в файл, а будет сохранен в переменной в памяти.

Если приложение может получить доступ к памяти незаконно, как можно защитить память от несанкционированного доступа?

Мы используем C ++ и XP (Vista / 7 может быть вариантом в будущем, поэтому я не знаю, изменит ли это ответ).


c++ memory-management protection memory windows-xp
person Community    schedule 25.05.2010    source источник
comment
Если система все еще находится на гибкой стадии процесса проектирования и внедрения, вы можете отказаться от развертывания собственной системы шифрования и переключиться на использование SSL / TLS для защиты связи между клиентом и сервером (желательно с использованием надежной сторонней библиотеки. разработан и сертифицирован специалистами по криптографии).   -  person Kitsune    schedule 25.05.2010

Ответы (4)


arrow_upward
4
arrow_downward

Я думаю, что у вас на руках более серьезная проблема.

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

В Windows процесс A может читать память процесса B, если выполняется одно из следующих условий:

  1. у него есть привилегии открывать запоминающее устройство.
  2. у него есть привилегии открывать виртуальную память процесса B.
  3. у него есть друг в ядре.

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

Это, конечно, не уникально для Windows. Уникальность Windows в том, что количество вредоносных программ-руткитов.

person bmargulies    schedule 25.05.2010
comment
Так что, даже если я сохраню ключи с помощью Windows DPAPI, а затем перенесу их в область памяти моего приложения, я все равно облажался? Это не очень обнадеживает :) Думаю, поэтому антивирус и последние обновления нужны как смягчающие факторы. - person ; 25.05.2010
comment
Это просто сужает окно. Если ключи даже мельком появляются в памяти, значит, они уязвимы. Некоторые люди скажут вам, что использование Windows - слишком высокий риск, если информация, которую необходимо защитить, имеет очень высокую ценность. - person bmargulies; 25.05.2010
comment
Информация о кредитной карте и требования теперь несколько строги. Я предполагаю, что единственный способ - это запрограммировать другие смягчающие факторы, которые помогут предотвратить сценарии руткитов. - person ; 25.05.2010

arrow_upward
4
arrow_downward

Ваш процесс распространения ключей небезопасен: если кто-то получит этот начальный набор ключей, все будет кончено.

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

person Andrew McGregor    schedule 25.05.2010

arrow_upward
2
arrow_downward

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

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

person Ukko    schedule 25.05.2010
comment
На самом деле просто ищу способ упростить и удобство ротации ключей и безопасной передачи конфиденциальной информации, поскольку наши клиенты слишком ленивы, чтобы менять ключи. Об SSL даже не может быть и речи ... - person ; 25.05.2010
comment
Можно возразить, что вы предоставляете покупателю песчаную яму, в которую он может засунуть свои покрытые перьями головы. Однако, не зная бизнес-контекста, трудно быть уверенным. - person bmargulies; 25.05.2010

arrow_upward
1
arrow_downward

На самом деле нет никакого способа предотвратить чтение памяти вашего процесса другими процессами.

Чтобы сделать вещи более устойчивыми к немотивированным атакам, вы можете рассмотреть возможность использования случайно сгенерированного ключа для шифрования реального ключа, когда он не используется. Вы можете генерировать новый случайный KEK каждый раз при запуске программы, возможно, даже изменяя его, когда программа выполняется каждые несколько секунд. Расшифровывайте «настоящий» ключ только тогда, когда вам действительно нужно его использовать, а затем сразу же обнуляйте память, где находится ключ, когда вы закончите.

Конечно, это не сработает, если вы постоянно общаетесь. Но если ваше общение большую часть времени находится в режиме ожидания и наблюдаются лишь случайные всплески трафика, этот подход может сработать.

person SoapBox    schedule 25.05.2010
comment
Интересный подход. Думаю, я могу разобраться в этом. - person ; 25.05.2010