Я понимаю, что задача скорее всего не имеет решения, но тема довольно обширная, поэтому не хочется упустить шанс ее решить.
Проблема в следующем: имеется exe-модуль, который ведет логирование в системе и записывает зашифрованные данные в файл. Также имеется клиентский модуль, который эти данные зачитывает через определенные промежутки времени, дешифруя файл лога. Так как все реализовано через .Net, то, естественно, декомпиляция кода рефлектором — лишь вопрос времени и желания.
Каким образом можно максимально осложнить подделку записей лога? Возможно как-то помогут алгоритмы шифрования с открытыми ключами или что-то в таком роде?... Если такая возможность даже теоретически отсутствует — все равно буду рад ответу и перестану рыть в эту сторону. В крайнем случае устроит максимально запутанный алгоритм шифрования, который можно прогнать через обфускатор и существенно осложнить поиск точек входа/выхода.

Здравствуйте, ice1, Вы писали:

I>Я понимаю, что задача скорее всего не имеет решения, но тема довольно обширная, поэтому не хочется упустить шанс ее решить.
I>Проблема в следующем: имеется exe-модуль, который ведет логирование в системе и записывает зашифрованные данные в файл. Также имеется клиентский модуль, который эти данные зачитывает через определенные промежутки времени, дешифруя файл лога. Так как все реализовано через .Net, то, естественно, декомпиляция кода рефлектором — лишь вопрос времени и желания.
I>Каким образом можно максимально осложнить подделку записей лога? Возможно как-то помогут алгоритмы шифрования с открытыми ключами или что-то в таком роде?... Если такая возможность даже теоретически отсутствует — все равно буду рад ответу и перестану рыть в эту сторону. В крайнем случае устроит максимально запутанный алгоритм шифрования, который можно прогнать через обфускатор и существенно осложнить поиск точек входа/выхода.

Злоумышленник может исследовать и клиент и сервер, или только клиент?

I>Я понимаю, что задача скорее всего не имеет решения, но тема довольно обширная, поэтому не хочется упустить шанс ее решить.
I>Проблема в следующем: имеется exe-модуль, который ведет логирование в системе и записывает зашифрованные данные в файл. Также имеется клиентский модуль, который эти данные зачитывает через определенные промежутки времени, дешифруя файл лога. Так как все реализовано через .Net, то, естественно, декомпиляция кода рефлектором — лишь вопрос времени и желания.
I>Каким образом можно максимально осложнить подделку записей лога? Возможно как-то помогут алгоритмы шифрования с открытыми ключами или что-то в таком роде?... Если такая возможность даже теоретически отсутствует — все равно буду рад ответу и перестану рыть в эту сторону. В крайнем случае устроит максимально запутанный алгоритм шифрования, который можно прогнать через обфускатор и существенно осложнить поиск точек входа/выхода.

Да, использование криптографии с открытыми ключами в любом случае будет нелишним, т.е. лог шифруется exe-модулем на секретном ключе (private key), а клиент его расшифровывает публичным ключом (public key). При этом, если у злоумышленника есть доступ к коду шифрующего модуля, то можно применить аппаратные ключи ("токены"), поддерживающие асимметричное шифрование.

Здравствуйте, andy1618, Вы писали:

A>Да, использование криптографии с открытыми ключами в любом случае будет нелишним, т.е. лог шифруется exe-модулем на секретном ключе (private key), а клиент его расшифровывает публичным ключом (public key).

Подскажите, а это возможно с использованием CryptoApi ? Может у меня рукие кривые, но получается расшифровать только приватным.

Здравствуйте, andy1618, Вы писали:

A>Да, использование криптографии с открытыми ключами в любом случае будет нелишним, т.е. лог шифруется exe-модулем на секретном ключе (private key), а клиент его расшифровывает публичным ключом (public key). При этом, если у злоумышленника есть доступ к коду шифрующего модуля, то можно применить аппаратные ключи ("токены"), поддерживающие асимметричное шифрование.

В моем случае ситуация обратная — для исследования доступен как раз тот модуль, который пишет зашифрованные записи, а тот что их дешифрует — недоступен, поэтому privat key как раз будет размещаться в доступном для исследования exe-шнике.

Здравствуйте, SergH, Вы писали:

SH>Злоумышленник может исследовать и клиент и сервер, или только клиент?

Я слегка запутался в терминах клиент/сервер. В данной ситуации наверное нет в чистом виде ни того, ни другого. Процесс, который собственно ведет логирование и зашифровывает записи, доступен для исследования. Приложение, которое эти записи зачитывает и дешифрует для исследования недоступно, т.к. находится на флешке у администратора и работает прямо с нее, не оставляя следов в системе.

Здравствуйте, _ICE_, Вы писали:

_IC>Я слегка запутался в терминах клиент/сервер. В данной ситуации наверное нет в чистом виде ни того, ни другого. Процесс, который собственно ведет логирование и зашифровывает записи, доступен для исследования. Приложение, которое эти записи зачитывает и дешифрует для исследования недоступно, т.к. находится на флешке у администратора и работает прямо с нее, не оставляя следов в системе.

Тогда открытый ключ не сильно поможет.

Здравствуйте, andy1618, Вы писали:

A>если у злоумышленника есть доступ к коду шифрующего модуля, то можно применить аппаратные ключи ("токены"), поддерживающие асимметричное шифрование.

Ну это уже черезчур жестко, но у меня зародилась такая мысль... Можно ли сделать так, что при старте Windows модуль логирования будет запускаться от имени другого пользователя (второго локального администратора Windows) и будет ли иметь процесс, запущенный таким образом, доступ к папкам, к которым открыт доступ только этому второму администратору? Если да, то можно просто создать второй админский аккаунт в системе, защитить его паролем, создать папку, дать к ней доступ только этому аккаунту и настроить автоматический запуск процесса от имени этого аккаунта. Теперь новый вопрос — возможно ли автоматически запустить процесс от имени другого аккаунта таким образом, чтобы не раскрывать пароля первому аккаунту?

Здравствуйте, Аноним, Вы писали:

A>>Да, использование криптографии с открытыми ключами в любом случае будет нелишним, т.е. лог шифруется exe-модулем на секретном ключе (private key), а клиент его расшифровывает публичным ключом (public key).

А>Подскажите, а это возможно с использованием CryptoApi ? Может у меня рукие кривые, но получается расшифровать только приватным.

Руки нормальные, AFAIK описанное не возможно. Но в данном случае достаточно не расшифровывать, а подписывать и верифицировать. Правда, в данном случае это тоже не помогает

Здравствуйте, SergH, Вы писали:

SH>Тогда открытый ключ не сильно поможет.

Точнее сказать — совсем не поможет, что я в общем-то и подозревал...

Здравствуйте, ice1, Вы писали:

A>>Да, использование криптографии с открытыми ключами в любом случае будет нелишним, т.е. лог шифруется exe-модулем на секретном ключе (private key), а клиент его расшифровывает публичным ключом (public key). При этом, если у злоумышленника есть доступ к коду шифрующего модуля, то можно применить аппаратные ключи ("токены"), поддерживающие асимметричное шифрование.

I>В моем случае ситуация обратная — для исследования доступен как раз тот модуль, который пишет зашифрованные записи, а тот что их дешифрует — недоступен, поэтому privat key как раз будет размещаться в доступном для исследования exe-шнике.

Может, не хранить ключ в exe-шнике, а выдавать сеансовый?

Здравствуйте, Socrat, Вы писали:

S>Может, не хранить ключ в exe-шнике, а выдавать сеансовый?

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

Здравствуйте, ice1, Вы писали:

I>Здравствуйте, andy1618, Вы писали:

A>>Да, использование криптографии с открытыми ключами в любом случае будет нелишним, т.е. лог шифруется exe-модулем на секретном ключе (private key), а клиент его расшифровывает публичным ключом (public key). При этом, если у злоумышленника есть доступ к коду шифрующего модуля, то можно применить аппаратные ключи ("токены"), поддерживающие асимметричное шифрование.

I>В моем случае ситуация обратная — для исследования доступен как раз тот модуль, который пишет зашифрованные записи, а тот что их дешифрует — недоступен, поэтому privat key как раз будет размещаться в доступном для исследования exe-шнике.

Размещайте в exe публичный ключ клиента и шифруйте им.

Здравствуйте, kig, Вы писали:

kig>Здравствуйте, ice1, Вы писали:

I>>Здравствуйте, andy1618, Вы писали:

A>>>Да, использование криптографии с открытыми ключами в любом случае будет нелишним, т.е. лог шифруется exe-модулем на секретном ключе (private key), а клиент его расшифровывает публичным ключом (public key). При этом, если у злоумышленника есть доступ к коду шифрующего модуля, то можно применить аппаратные ключи ("токены"), поддерживающие асимметричное шифрование.

I>>В моем случае ситуация обратная — для исследования доступен как раз тот модуль, который пишет зашифрованные записи, а тот что их дешифрует — недоступен, поэтому privat key как раз будет размещаться в доступном для исследования exe-шнике.

kig>Размещайте в exe публичный ключ клиента и шифруйте им.

Сорри. Ветку невнимательно прочитал.
В Вашем случае не поможет.

Здравствуйте, kig, Вы писали:

kig>Размещайте в exe публичный ключ клиента и шифруйте им.

Насколько я понимаю это не решит проблемы. Exe-модуль по прежнему можно декомпилировать и внести в него изменения, чтобы он имел возможность "подделывать" записи лога.

Здравствуйте, kig, Вы писали:

kig>Сорри. Ветку невнимательно прочитал.
kig>В Вашем случае не поможет.
Вот-вот...
Оба модуля подписаны одним ключем + есть одна разделяемая Shared библиотека, подписанная им же, но в данном случае это не помогает.

Здравствуйте, SergH, Вы писали:

SH>Тогда открытый ключ не сильно поможет.

Если информацию, зашифрованную открытым ключем нельзя прочесть без секретного ключа, то напрашивается такое решение:
У меня есть такие записи лога: системные события (старт/стоп и др.), и несколько типов записей, касающихся собственно предмета логирования.
Каждый из типов записи представляют собой наследника от одного абстрактного класса записи лога. Запись в лог представляет собой бинарную сериализацию экземпляра записи, шифрацию полученного бинарного массива и запись результата в файл. В базовом классе делаем сериализуемое поле любого типа, в которое при старте логирующего процесса записываем некую случайную информацию (например для надежности — массив байт из Random.NextBytes()). Каждая запись лога в течении одного сеанса (т.е. в момент от первой записи "Старт" до следующей записи "Старт") должна иметь идентичное значение этого контрольного поля. Таким образом если "злоумышленник" вставит внутрь лога собственную запись — ее можно вычислить по несовпадению значения этого поля, а невозможность дешифрации уже записанных записей без секретного ключа не даст ему прочесть последние записи лога и скопировать значение.
Единственным очевидным вариантом обхода останется подключение к запущенному процессу и считывание значения контрольного поля при помощи рефлексии, но это уже требует некоторой подготовки от взломщика и повысит стойкость защиты.

Здравствуйте, andy1618, Вы писали:

A>Да, использование криптографии с открытыми ключами в любом случае будет нелишним, т.е. лог шифруется exe-модулем на секретном ключе (private key), а клиент его расшифровывает публичным ключом (public key). При этом, если у злоумышленника есть доступ к коду шифрующего модуля, то можно применить аппаратные ключи ("токены"), поддерживающие асимметричное шифрование.

Т.е. прога с зашитым в нее приватным ключом лежит общедоступно а прога с зашитым публичным как раз спрятана? Оригинально-с!

Здравствуйте, CreatorCray, Вы писали:

CC>Т.е. прога с зашитым в нее приватным ключом лежит общедоступно а прога с зашитым публичным как раз спрятана? Оригинально-с!

Пока прямой угрозы взлома нет, система только начала работать на 4-х реальных точках, но в будущем есть угроза что кто-нибудь из пользователей начнет поиск путей взлома системы. Сейчас шифрация идет самым простым методом с одним ключем, и я ищу способ как можно надежнее защититься от взлома.
Проблему Вы, кстати, поняли неверно. Задача не в том, чтобы защитить записи от дешифрации — проблема в том, чтобы сделать невозможным зашифровать "липовую" запись даже имея на руках исходники шифрующего модуля.

Здравствуйте, _ICE_, Вы писали:

A>>>Да, использование криптографии с открытыми ключами в любом случае будет нелишним, т.е. лог шифруется exe-модулем на секретном ключе (private key), а клиент его расшифровывает публичным ключом (public key).
I>>>В моем случае ситуация обратная — для исследования доступен как раз тот модуль, который пишет зашифрованные записи, а тот что их дешифрует — недоступен, поэтому privat key как раз будет размещаться в доступном для исследования exe-шнике.
CC>>Т.е. прога с зашитым в нее приватным ключом лежит общедоступно а прога с зашитым публичным как раз спрятана? Оригинально-с!

_IC>Пока прямой угрозы взлома нет, система только начала работать на 4-х реальных точках, но в будущем есть угроза что кто-нибудь из пользователей начнет поиск путей взлома системы. Сейчас шифрация идет самым простым методом с одним ключем, и я ищу способ как можно надежнее защититься от взлома.
Использовать ассиметрик для шифрования файла лога напрямую — не самая лучшая идея.
Кроме того прочитай еще раз выделенное. У тебя там грубейшая ошибка применения: если у тебя приватный ключ выложен в открытый доступ (читай "privat key как раз будет размещаться в доступном для исследования exe-шнике") — считай что шифрования у тебя нету вообще. Приватный ключ на то и приватный что его надо держать в секрете. Всегда.

_IC>Проблему Вы, кстати, поняли неверно. Задача не в том, чтобы защитить записи от дешифрации — проблема в том, чтобы сделать невозможным зашифровать "липовую" запись даже имея на руках исходники шифрующего модуля.
Проблема в том, что тебе надо постоянно дописывать в файл. Если бы тебе надо было бы защитить однократно записанные данные от модификации — такой проблемы бы не было.
Но тебе надо защищать данные пока они на диске. Причем ты и записывающая и читающая(тебе же надо убедиться что данные к которым ты дописываешь не были модифицированы) сторона.
Простого решения похоже нет. Надо искать варианты.

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