privat key как раз будет размещаться в доступном для исследования exe-шнике. CC>Кроме того прочитай еще раз выделенное. У тебя там грубейшая ошибка применения: если у тебя приватный ключ выложен в открытый доступ (читай "privat key как раз будет размещаться в доступном для исследования exe-шнике") — считай что шифрования у тебя нету вообще. Приватный ключ на то и приватный что его надо держать в секрете. Всегда.
Да это я как раз написал только как ответ на сообщение, чтобы показать невозможность применения Privat/Public key в чистом виде. Сейчас шифрование применяется по простому алгоритму с одним ключом для шифрации/дешифрации только для того, чтобы исключить возможность модификации (или просмотра) записей лога с помощью какого-нибудь блокнота или Hex-редактора.
CC>Проблема в том, что тебе надо постоянно дописывать в файл. Если бы тебе надо было бы защитить однократно записанные данные от модификации — такой проблемы бы не было. CC>Но тебе надо защищать данные пока они на диске. Причем ты и записывающая и читающая(тебе же надо убедиться что данные к которым ты дописываешь не были модифицированы) сторона.
Скажем так... Вопрос дозаписи в лог посторонней информации некритичен, куда важнее защитить лог от стирания уже существующих записей. Самый простой способ — скопировать файл лога до выполнения некой операции и заменить его уже после выполнения. Эту проблему я решаю с помощью "мониторных" записей — логирующий модуль с определенным интервалом скидывает в лог информацию о том, что он жив и работает, а при импорте лога в модуле аудита я анализирую интервалы времени между такими записями и если они выше критического установленного порога — регистрирую это событие и информирую администратора.
Также это защищает от возможных попыток заморозить или приостановить логирующий процесс каким-нибудь способом и тому подобных действий.
CC>Простого решения похоже нет. Надо искать варианты.
Пара вариантов мне уже пришла в голову в процессе обсуждения: Здесь
CC>Как вариант: накопление данных в памяти и окончательная запись на диск небольшими порциями (каждый час например), каждую из которых подписываешь с использованием открытого ключа.
Думал. Опасно. Банальный диспетчер задач или зависание системы (по любому поводу, возможно спровоцированное) лишает лог информации на значительное время и довольно трудно доказать что именно послужило причиной такого разрыва — злой умысел или какой-то форсмажор.
Здравствуйте, ice1, Вы писали:
I>privat key как раз будет размещаться в доступном для исследования exe-шнике. CC>>Кроме того прочитай еще раз выделенное. У тебя там грубейшая ошибка применения: если у тебя приватный ключ выложен в открытый доступ (читай "privat key как раз будет размещаться в доступном для исследования exe-шнике") — считай что шифрования у тебя нету вообще. Приватный ключ на то и приватный что его надо держать в секрете. Всегда.
I>Да это я как раз написал только как ответ на сообщение, чтобы показать невозможность применения Privat/Public key в чистом виде.
Почему невозможность? К примеру RSA позволяет осуществлять шифрование как публичным так и приватным (Private) и соответственно расшифровывать противоположным ключом. Так что можно хранить в публичном ехе публичный ключ.
В чистом виде их никогда и не используют. Любая защита это комплекс.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, _ICE_, Вы писали:
_IC>Здравствуйте, andy1618, Вы писали:
A>>если у злоумышленника есть доступ к коду шифрующего модуля, то можно применить аппаратные ключи ("токены"), поддерживающие асимметричное шифрование.
_IC>Ну это уже черезчур жестко, но у меня зародилась такая мысль... Можно ли сделать так, что при старте Windows модуль логирования будет запускаться от имени другого пользователя (второго локального администратора Windows) и будет ли иметь процесс, запущенный таким образом, доступ к папкам, к которым открыт доступ только этому второму администратору? Если да, то можно просто создать второй админский аккаунт в системе, защитить его паролем, создать папку, дать к ней доступ только этому аккаунту и настроить автоматический запуск процесса от имени этого аккаунта. Теперь новый вопрос — возможно ли автоматически запустить процесс от имени другого аккаунта таким образом, чтобы не раскрывать пароля первому аккаунту?
Есть ли возможность использовать модуль логирования в виде сервиса, запущеннего из под учетной записи, пароль которой известен только Вам?
Если да, тогда можно рассмотреть возможность использовать DPAPI, зашифровав под этой учетной записью с тем же паролем, например, закрытый ключ для подписывания сообщений лога, в программе "конфигурирования" сервиса и сохранить его. В сервисе использовать DPAPI для дешифровки закрытого ключа.
Здравствуйте, kig, Вы писали:
kig>Есть ли возможность использовать модуль логирования в виде сервиса, запущеннего из под учетной записи, пароль которой известен только Вам? kig>Если да, тогда можно рассмотреть возможность использовать DPAPI, зашифровав под этой учетной записью с тем же паролем, например, закрытый ключ для подписывания сообщений лога, в программе "конфигурирования" сервиса и сохранить его. В сервисе использовать DPAPI для дешифровки закрытого ключа.
