2016-07-11 4 views
0

Мое приложение использует буферы протокола Google для отправки конфиденциальных данных между экземплярами клиента и сервера. Сетевая ссылка зашифрована с помощью SSL, поэтому я не беспокоюсь о подслушивающих устройствах в сети. Я беспокоюсь о фактической загрузке чувствительных данных в protobuf из-за проблем с памятью, описанных in this SO question.Наиболее безопасный способ загрузки конфиденциальной информации в буферы протоколов

Например:

Login login = Login.newBuilder().setPassword(password)// problem 
           .build(); 

Неужели нет способа сделать это безопасно, так как протокол буферы неизменны?

ответ

3

Protobuf не предоставляет никакой возможности использовать char[] вместо String. Напротив, сообщения Protobuf намеренно проектируются так, чтобы быть полностью неизменными, что обеспечивает различную защиту: вы можете совместно использовать один экземпляр сообщения между несколькими изолированными компонентами программы, не опасаясь, что можно изменить данные, чтобы помешать другому ,

По моему личному мнению, как инженер безопасности - хотя другие не согласятся - на «безопасность», описанной в вопросе SO, к которому вы связать это театр безопасности, на самом деле не стоит, по целому ряду причин:

  1. Если злоумышленник может прочитать память вашего процесса, вы уже проиграли. Даже если вы перезаписываете секретную память перед ее отбрасыванием, если злоумышленник читает вашу память в нужное время, они найдут пароль. Но, что еще хуже, если злоумышленник в состоянии прочитать память вашего процесса, они, вероятно, могут сделать гораздо хуже, чем извлекать временные пароли: они могут, вероятно, извлечь долгоживущие секреты (например, закрытый ключ TLS вашего сервера) , перезаписать части памяти, чтобы изменить поведение вашего приложения, получить доступ к любым ресурсам, к которым у вашего приложения есть доступ, и т. д. Это просто не проблема, которая может быть осмысленно решена путем обнуления определенных полей после использования.

  2. Реалистично, есть слишком много способов, что ваши секреты могут быть скопированы в любом случае, в течение которого вы не имеете никакого контроля, делая все упражнения спорное:

    • Даже если вы осторожны, сборщик мусора может иметь сделал копии секретности, перемещая память вокруг, победив цель. Чтобы этого избежать, вам, вероятно, необходимо использовать ByteBuffer, поддерживаемый не управляемой памятью.
    • При чтении данных в ваш процесс почти наверняка проходит через библиотечный код, который не перезаписывает свои данные таким образом. Например, InputStream может выполнять внутреннюю буферизацию и, вероятно, после этого не выключает свой буфер.
    • Операционная система может вывести ваши данные для замены места на диске в любое время и не обязана затем обнулять эти данные. Поэтому, даже если вы обнулите память, она может сохраняться при обмене данными. (Шифрование смены гарантирует, что эти секреты эффективно исчезнут, когда система отключится, но не обязательно защитит от злоумышленника, присутствующего на локальном компьютере, который может извлечь ключ шифрования подкачки из ядра.)
    • И т.д.

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

+0

KeePass делает кое-что об использовании API защиты окон Windows для защиты данных в памяти.Я не знаю, действительно ли DPAPI хорош или нет (больше театра?). Есть предположения? – bazza

+1

@bazza Возможно, что я чего-то не хватает, но AFAICT это в первую очередь защищает от оффлайн-атак на выгружаемой памяти. Использование зашифрованного свопа будет иметь такой же эффект. Онлайн-атаки могут легко расшифровать память, так как онлайновый злоумышленник (вредоносный процесс, работающий под той же учетной записью пользователя) может просто вызвать DPAPI для дешифрования. –

+0

Хмм, прочитав больше http://keepass.info/help/base/security.html, кажется, что они используют его для хранения ключа, который используется для шифрования/дешифрования данных в памяти. Так что нет, я не думаю, что вы что-то пропустили, я слишком много читал в маленьких кусочках, которые я видел в другом месте! Интересные комментарии на этой странице о различиях между Mono и Windows. – bazza

Смежные вопросы