помогите пожалуйста разобраться...
я пишу свое приложение(на C#), которое функционирует в виде слубы windows с правами SYSTEM. Само приложение ничего особенного не делает... кроме как подгружает dll, которые приходят по сетке в зашифрованном виде. Оно их расшифровывает на своем private ключе... у приложения есть сертификат(который лежит в хранилище windows) и передает управление туда...
Полный алгорит работы такой:
1. принять зишифрованный и подписанный xml
2. проверить подпись сервера
3. расшифровать
4. загрузить dll
5. запустить метод run()

Соответственно возникают две проблемы:
1. Как защититься от загрузки чужих dll и их выполнения с правами SYSTEM... их код может быть вредоносным.
В данном примере такой защиты нет. В самом приложении я беру из хранилища windows сертификат сервера по серийному номеру(это для проверки подписи). Простым дизассемблированием и изменением этого номера я добиваюсь того, что вытаскивается сертификат лжесервера и сообщение от лжесервера проходит верификацию подписи. Public моего приложения открыт и, следовательно, я смогу зашифровать хакерскую dll и тогда мое приложение ее благополучно расшифрует...а затем запустит под system.

2. Насколько я понял существет всего несколько способов взаимодействия из ПО с собственными сертификатами. Использование pfx файла для хранения private ключа и использование хранилища windows.
В первом случае возможно унести сертификат домой и там пытаться подобрать пароль к pfx перебором.
Да и в самой программе зашит код... простым реверсом его можно выдернуть. Во втором случае - кладем в хранилище и запрещаем export private ключа. Т..о. за секретный ключ теперь отвечает винда. Тогда при работе приложения с сертификатом можно либо запрашивать пароль(сама система это делает), либо разрешение(подтверждение), либо ничего. В случае сервиса остается вариант не использовать ничего, чтобы не вылетали постоянно окна. Но тогда любое приложение сможет на этом компютере сможет подписать сообщение ключом из этого сертификата. А такое тоже не очень хорошо.
Есть ли какие-нибудь другие варианты хранения своего закрытого ключа?

Как вариант затруднения анализа кода можно применить обфускатор... но только судя по статье "реверсинг .net приложений .." это не очень-то и поможет....

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

Не уверен что правильно понял, что нужно, но если ты хочешь разрешить выполнение только своих dll, то необходимо и достаточно либо подписать их, либо пошифровать любым стойким алго. Если у злоумышленника есть возможность получить приложение для анализа (а стало быть и ключ расшифровки), алгоритм должен быть ассиметричным - ты шифруешь приватным ключем, а расшифровка идёт публичным. Приватный ключ, разумеется, должен храниться у тебя в сухом и прохладном месте, а не в каком-то там хранилище юзера.

| Сообщение посчитали полезным:

S_T_A_S_ пишет:
Не уверен что правильно понял, что нужно, но если ты хочешь разрешить выполнение только своих dll, то необходимо и достаточно либо подписать их, либо пошифровать любым стойким алго.

Да... мне надо именно разрешить выполнение только своих DLL. У злоумышленника есть возможность получить приложение для анализа. Тогда шифрую приватным, а расшифровываю публичным. Согласен.
Только я вот не совсем до конца понимаю механизм. Предположим я зашифровал свою dll используя закрытый ключ. Открытый я беру на стороне клиента из сертификата(сам сертификат могу хоть в хранилище, хоть куда положить). Вопрос в том, что мешает злоумышленнику подменить в программе несколько строк так, чтобы расшифровка велась на его открытом ключе. А зашифрует он свою враждебную dll на своем закрытом ключе. И тогда все замечательно расшифруется и запустится.
Или я где-то не прав?

| Сообщение посчитали полезным:

d4u пишет:
И тогда все замечательно расшифруется и запустится.
Весь вопрос где запустится. Если у злоумышленника на его компе, так наплевать. А если предположить, что злоумышленник взломал комп, где находится эта система и имеет права, чтобы её изменить (я понял права админа) тогда он и так может делать, чего хочет и без использования удалённой вредоносной DLL.

| Сообщение посчитали полезным:

Все...понял... согласен со S_T_A_S_ и Player. От загрузки чужеродных dll можно защититься зашифровав их ассиметричным алгоритмом. Спасибо!
Остается открытым второй вопрос: можно ли сделать так, чтобы закрытым ключом сертификата x509 пользовалось только мое приложение-сервис... т.е. чтобы нельзя было подделать подпись.

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

Ну да... алгоритм примерно такой: сервер генерирует сессионный ключ и шифрует его на паблик ключе клиентского приложения. Затем пересылает ему и далее траффик шифруется на этом ключе симметричным алгоритмом... хотелось сначал сделать получение сессионного ключа по Диффи-Хеллману, но дело в том, что не срастаются реализации на C# и JAVA, а свое придумывать не очень хотелось
Здесь опять же косяк возникает... любое приложение на этом компе может расшифровать сообщение сервера и выступить посредником.... ибо доступ к private ключу (из сертификата) я не могу закрыть, потому что неудобно запрашивать пароль для доступа, как я и писал выше.

| Сообщение посчитали полезным:

Дык если клиент коннектится только к твоему серверу, откуда может взяться левая dll?

| Сообщение посчитали полезным:

я сам запутался)
Чужую длл никак не сунуть в существующей схеме. Мой первый пост был уже ошибочным. Спасибо, что помогли разобраться.

| Сообщение посчитали полезным: