Шифрование данных в ОЗУ

[Protopopulus]

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

[rayanAyar]

В библиотеке FCL есть TBlowFishEncryptStream/TBlowFishDeCryptStream.
Есть набор компонентов dcpcrypt2-laz (http://wiki.lazarus.freepascal.org/DCPcrypt). В нем практически полный набор всех актуальных алгоритмов шифрования.

[Max Rusov]

Задача несколько нетривиальна - создать максимально защищенную программу, в том числе защитить от изменений в ходе выполнения

Какая то нелепая задача. Защищенность программы от этого ни капельки не вырастет.

[v-t-l]

Ага, т.к. ключи и алгоритмы дешифрования будут находится в ОЗУ в незашифрованом виде.

[Ism]

Вам поможет http://ru.wikipedia.org/wiki/Обфускация

А ключи нужно не шифровать, а хитро прятать в памяти

[debi12345]

Проще и разумнее всего это сделать для уже собранной программы. Для чего купить или стырить ASPack, Armadillo и прочие-прочие рантайм-онфлай-[де]криптеры - нужны те, которые поодрживают режим декрипиовки только текущей исполняеимой секци кода . Хотя може появлись и фиварные-оперсорсные утилитту такого класса, не знаю. Кто знает - скажите !

Еще вариант - использовать шифрующий SQLite3 ( SQLiteCipher - если решитесь, то у меня есть собранные DLL & EXE и для Линуска, и для Выни). Тогда можно важные данные хранить в шифрованной БД, и вытаскивать их через SQL на короткое время, обрабатывать и опять записывать в БД - это избавит он необходимоти держать их постоянно в ОЗУ. Дополнительный бонус - эти данные можно осталять в БД поле обработки, потому что даже имея доступ к БД, ти данные хрен прочитаешь без пароля, БД кодируется кажется AES256.

Можно также писать в шифрованный файл вместо БД - рекомендую сервис библиотеки OpenSSL. Долго мучился прежде чем получить "рабочую лошадку" из оной под MSE - но теперь в ус не дую Вариант OpenSSL хорош тем,что ожно использовать открытые ключи с шифровкой приватного ключа.

Добавлено спустя 3 минуты 30 секунд:

ешифрования будут находится в ОЗУ в незашифрованом виде.

Ясен перец, что нужен парольный (или через ауфтокен) вход в программу - и уже эти паролем на нужное КОРОТКОЕ время декодировать ключи, а уже этими ключами - данные, и т.п.

[Protopopulus]

Возможно, меня немного неправильно поняли... Хотя, дельные советы действительно дали. Попробую "на пальцах" изложить суть вопроса.

Допустим, создаем массив в памяти:

Код: Выделить всё

Arr = array[0..1000];
PArr = ^Arr;

Далее, работаем через ссылку с массивом. Каким образом поместить уже зашифрованный массив в память, без дополнительных телодвижений в виде классов Блоуфиша и им подобных? И как сделать такую работу "прозрачной" для программы? Есть ли в компиляторе некий защищенный режим или что-то похожее?

Какая то нелепая задача. Защищенность программы от этого ни капельки не вырастет.

Можно поинтересоваться по какой причине?

[alexs]

Зачем шифровать в памяти?
Если злоумышлиник получил физический доступ к железу - никакая шифрация не спасёт.
Скорее всего ваша исходная проблема должна решаться не на уровне вашей программы - а на организационном уровне.

[Protopopulus]

Так задача именно организационного уровня. Шифрование томов жесткого диска у меня и так включено, iptables режет любой "левый" трафик, SELinux следит за процессами, я работаю без административных прав. Но, допустим, я параноик и хочу шифровать данные, которые попадают в память. Есть ли для этого средства?

[alexs]

П.1.
Если вы тут же в памяти держите алгоритм дешифрования и ключи - то задача безсмыслена.
П.2.
А если нет - то как вы эти данные собираетесь использовать? следственно - см. п.1

В вашей ситуации надо обеспечить что на том устройстве, под которое вы пишите не было не доверенного софта.
Чтобы не было возможности взлома системы.

Если вредоносный код уже запущен и он проник в адресное пространство вашего процесса - то шифрование данных не спасёт.

[dunin]

...Но, допустим, я параноик...

http://www.itsecurity.ru/edu/kurs/bt_01.html

[Alek_Aaz]

Так задача именно организационного уровня. Шифрование томов жесткого диска у меня и так включено, iptables режет любой "левый" трафик, SELinux следит за процессами, я работаю без административных прав. Но, допустим, я параноик и хочу шифровать данные, которые попадают в память. Есть ли для этого средства?

Теоретически. Нужно ставить "свой" контроллер ОЗУ который будет шифровать данные отправляемые в память. Для Intel еще можно придумать, для AMD - нереально. Если край как надо и денег мешочек с вагончиком то можно реализовать все на OpenSPARC и FPGA. Процессор SPARC, на нем запускать Linux , а там эмулятор х86. Есть еще FPGA с защитой от взлома ... Гыыы...

[wavebvg]

П.1.
Если вы тут же в памяти держите алгоритм дешифрования и ключи - то задача бессмыслена.

Как раз наоборот, чтобы получить из памяти и исполнить чужой алгоритм шифрования (причем умудриться при этом утянуть и сам активный ключ для расшифровки) - нужно потратить кучу времени и сил на разработку такого решения, его испытание и тестирование, а про исследовательскую часть задачи расшифровки - вообще молчу.
С другой стороны, если есть процесс передачи данных, то его можно легко использовать для извлечения данных, которые зашифрованы (если они расшифровываются). Да и в любом случае попытка использовать зашифрованные данные - это потенциальная угроза безопасности, так что лучше их вообще не запоминать тогда.

Но, допустим, я параноик и хочу шифровать данные

Если вредоносный код уже запущен и он проник в адресное пространство вашего процесса - то шифрование данных не спасёт.

И кто же тут параноик?

Моё личное мнение - достаточно использовать свой проприетарный формат храниения данных и зашифровать модифицированным алгоритмом - этого вполне достаточно, чтобы затянуть время несанкционированного извлечения данных именно в этом "узком" месте на "годы".
Самая простая реализация - читалка/писалка для TStream с возможностью работы с данными в незашифрованном и зашифрованном виде (в случае с памятью - TMemoryStream в качестве хранилища)

[Padre_Mortius]

могу предположить ситуацию, что ТС собирается данные сначала раскриптовывать данные, а потом с ними работать.

Как раз наоборот, чтобы получить из памяти и исполнить чужой алгоритм шифрования (причем умудриться при этом утянуть и сам активный ключ для расшифровки) - нужно потратить кучу времени и сил на разработку такого решения, его испытание и тестирование, а про исследовательскую часть задачи расшифровки - вообще молчу

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

[wavebvg]

В большинстве случаев снимаем дамп памяти и практически сразу получаем данные в расшифрованном виде. Работать с зашифрованными данными малость не удобно.

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