.Net Шифрование

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

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

  2. Если я развертываю свое приложение на пользовательских машинах в корпоративной среде и у приложения есть строки подключения в файле конфигурации, как я могу убедиться, что только мое приложение может его расшифровать? Этот сценарий особенно интересен в сценарии развертывания ClickOnce. Я читал о людях, которые хранят конфигурацию в незашифрованном виде на сервере издателя и шифруют на уровне компьютера, когда приложение загружается, устанавливается и запускается в первый раз. Для меня это звучит так неправильно - строки подключения беззащитно передвигаются по сети и остаются незащищенными в течение короткого промежутка времени между загрузкой и выполнением приложения.

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

  4. Поскольку я использую ClickOnce, я мог бы иметь зашифрованную конфиденциальную информацию в коде или встроить, потому что ClickOnce не обнаружит изменения, если не изменится версия #. Итак, если мне нужно перекомпилировать, если я изменю строку подключения, точка app.config будет отключена. Какие еще подходы я могу предпринять, не используя файл конфигурации, для защиты строк подключения на сервере, клиенте и между ними?


encryption .net connection-string clickonce app-config
person Gus Cavalcanti    schedule 21.05.2009    source источник
comment
Не могли бы вы подробнее описать свой 1-й вопрос? Что такое шифрование на уровне машины?   -  person nightcoder    schedule 22.05.2009
comment
Насколько мне известно, вы можете использовать встроенное шифрование для шифрования на уровне машины и пользователя. Например, с помощью configSection.SectionInformation.ProtectSection (RSAProtectedConfigurationProvider); или через aspnet_regiis.exe   -  person Gus Cavalcanti    schedule 22.05.2009
comment
Возможно, было бы разумнее уточнить ваш предыдущий вопрос, заданный вчера (stackoverflow.com/questions/890396/), чем создать дублирующий вопрос, сформулированный по-другому.   -  person Mark Carpenter    schedule 22.05.2009
comment
Сегодняшний однозначный подход к шифрованию - это завтрашнее безумие. Ну, это похоже.   -  person Demi    schedule 22.05.2009

Ответы (4)


arrow_upward
13
arrow_downward

  1. да. Секреты, зашифрованные с помощью машинного ключа, могут быть расшифрованы любым процессом, имеющим доступ к машинному ключу. Секреты, зашифрованные с помощью пользовательского ключа, могут быть расшифрованы любым процессом, запущенным одним и тем же пользователем.
  2. Это невозможно. Все противоположные утверждения - это змеиное масло. Вашему приложению нужен секрет, чтобы что-то расшифровать. Нет известных схем, чтобы скрыть секрет внутри приложения. Существуют различные схемы обфускации, но ничего пуленепробиваемого. Лучшее, что вы можете сделать, - это поднять планку.
  3. Нет. Либо у приложения есть секретный ключ для расшифровки чего-либо, и в этом случае вы вернетесь к пункту 2, либо у вашего приложения есть открытый ключ, и в этом случае любой может расшифровать тот же секрет, поэтому вы в основном выполняете проверку конфигурации. (не подделывались), но конфигурация не секрет.
  4. Вы не можете безопасно развернуть встроенные секреты в приложении. Вопрос только в том, насколько высока цена, если ваш защищенный актив (секрет) того стоит, то его получит хакер.

Инфраструктура шифрования предназначена для защиты секретов текущего пользователя от других пользователей. Он не предназначен для защиты секретов приложения от пользователя, который его использует. Вы просите не о шифровании, а о DRM, и вам нужно заглянуть в инфраструктуру DRM, чтобы получить ответы. Мне неизвестна управляемая библиотека для DRM API < / а>.

person Remus Rusanu    schedule 21.05.2009
comment
Спасибо Русану. Я ценю вашу помощь. - person Gus Cavalcanti; 22.05.2009

arrow_upward
3
arrow_downward

На самом деле хороший вопрос,

Вы не можете быть уверены, что никто не расшифрует вашу строку подключения (или пароль). Конечно, вы можете его зашифровать, но люди смогут декомпилировать ваше приложение и посмотреть, какой алгоритм шифрования вы используете и какой ключ вы используете для расшифровки строки подключения / пароля. Может, это больше похоже на экстрим, но возможно (в студенческие годы я был злым взломщиком :)). Так что, если вы боитесь такого сценария, вам нужно защитить свое приложение, усложнив его разборку. Это тема для другого обсуждения, но, например, вы можете использовать Dotfuscator или другой хороший обфускатор - взломщику будет сложнее понять, что происходит внутри вашего приложения.
Итак, одним из возможных решений может быть «зашифровать строку подключения + использовать обфускатор», но, как я уже сказал, это будет не даст вам 100% защиты.

person nightcoder    schedule 21.05.2009

arrow_upward
2
arrow_downward

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

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

person tanascius    schedule 21.05.2009

arrow_upward
0
arrow_downward

Густаво, возможно, вы сможете это реализовать (это мой план для моего приложения, основанного на входе в систему).

Пользователь вводит учетные данные в приложении .Net. Учетные данные передаются в серверное приложение .php, которое использует их для входа в базу данных, получения ключа и передачи его обратно в приложение .Net. Затем ключ используется в жестко закодированных зашифрованных строках подключения в приложении .Net, чтобы обеспечить полный доступ к базе данных.

person Theveloper    schedule 10.05.2012