После многих часов гугления и поиска на тематических сайтах, включая любимый RSDN, не было найдено ни одного внятного рецепта. Братья-коллеги по цеху! Помогите — я уже погибаю по тоннами ненужной информации!
Я недавно закончил разработку приложения Windows Forms с использованием набора практик Microsoft Smart Client Software Factory. Настал самый ответственный момент — Deployment. Приложение не защищено лизензией или паролем, в нем нет защиты от копирования. Данное приложение можно свободно копировать и передавать третьим лицам. В общем все что угодно. Но! Приложение нельзя изменять и переконфигурировать — это имею право делать только я, автор приложения. В составе приложение есть два файла, которые нужно зашифровать, чтобы предотвратить его несанкционированную модификацию — File1.xml и File2.xml.
Чего хотелось бы добиться: я с помощью приватного ключа известного только мне, шифрую эти файлы и в зашифрованном виде включаю их в дистрибутив. Вместе с зашифрованными файлами я включаю в дистрибутив некий публичный ключ, который подходит только для расшифровки. Т.е. имея этот ключ программа, установленнная на компьютере пользователя сможет только прочитать данные из дешифрованного конфигурационного файла. Т.е. сами данные секретом не являются — пользователь может взять публичный ключ и с помощью какой-либо утилиты дефивровать файлы. Я и не буду стараться его особо спрятать, могу вообще положить рядом с зашифрованными файлами с именем "KeyForDecryptConfigs.xml" Проблемы у него должны появиться тогда, когда он попытается изменить дешифрованные файлы и снова запаковать их, чтобы подсунуть моей программе. Ведь у него не будет моего приватного ключа! Следовательно ничего зашифровать он не сможет — следовательно программа не сможет расшифровать корректно те данные которые ей будут пытаться подсунуть и завершит выполнение с соответствующим сообщением об ошибке...
Реализовать подобное поведение я решил с помощью классической схемы, предложенной в MSDN — сами данные шифруются симметричным алгоритмом RijndaelManaged а его ключ шифруется с помощью RSACryptoServiceProvider. Но вот чего я никак не могу понять — как в этой схеме зашифровать данные приватным ключом и дать пользователю (читай — программе) публичный ключ и зашифрованные данные, чтобы она их расшифровывала этим публичным ключом?

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

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

DRS><skipped>

Если вам нужно только проверить целостность файлов, а их содержимое не является тайной, то используйте цифровую подпись вместо шифрования.

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

MC>XML-файлы шифруете с помощью RSA приватным ключом, который хранится только у вас. В приложении же хранится публичный ключ, с помощью которого расшифровываете файлы, после чего загружаете конфигурацию.

Ну собственно это и был мой вопрос! Я пока не знаю как это сделать. И остается нерешенным вопрок о контейнерах ключей... Я в общем-то нашел пару ответов по поводу хэширования здесь — но это мне не подходит.

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

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

DRS>><skipped>

K>Если вам нужно только проверить целостность файлов, а их содержимое не является тайной, то используйте цифровую подпись вместо шифрования.

В общем-то чем дальше копаю — тем ближе к аналогичной мысли... Уже нашел здесь рецепт проверки цифровой подписи с помощью RSA. Но хотелось бы все-таки зашифровать файл... На всякий случай

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

DRS>Чего хотелось бы добиться: я с помощью приватного ключа известного только мне, шифрую эти файлы и в зашифрованном виде включаю их в дистрибутив. Вместе с зашифрованными файлами я включаю в дистрибутив некий публичный ключ, который подходит только для расшифровки. Т.е. имея этот ключ программа, установленнная на компьютере пользователя сможет только прочитать данные из дешифрованного конфигурационного файла. Т.е. сами данные секретом не являются — пользователь может взять публичный ключ и с помощью какой-либо утилиты дефивровать файлы. Я и не буду стараться его особо спрятать, могу вообще положить рядом с зашифрованными файлами с именем "KeyForDecryptConfigs.xml" Проблемы у него должны появиться тогда, когда он попытается изменить дешифрованные файлы и снова запаковать их, чтобы подсунуть моей программе. Ведь у него не будет моего приватного ключа! Следовательно ничего зашифровать он не сможет — следовательно программа не сможет расшифровать корректно те данные которые ей будут пытаться подсунуть и завершит выполнение с соответствующим сообщением об ошибке...

Я не специалист в этой теме, но описанное больше похоже на цифровую подпись.

Mumitroller

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

DRS>В общем-то чем дальше копаю — тем ближе к аналогичной мысли... Уже нашел здесь рецепт проверки цифровой подписи с помощью RSA. Но хотелось бы все-таки зашифровать файл... На всякий случай

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

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

DRS> Но вот чего я никак не могу понять — как в этой схеме зашифровать данные приватным ключом и дать пользователю (читай — программе) публичный ключ и зашифрованные данные, чтобы она их расшифровывала этим публичным ключом?

А мне вот интересно, что помешает пользователю заменить ваш открытый ключ своим...

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

А>А мне вот интересно, что помешает пользователю заменить ваш открытый ключ своим...
Господи — да пусть меняет. Ну расфифрует он данные, ну изменит их. Но зашифровать-то измененный файл он обратно не сможет! У него же нет приватного ключа!

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

А>>А мне вот интересно, что помешает пользователю заменить ваш открытый ключ своим...
DRS>Господи — да пусть меняет. Ну расфифрует он данные, ну изменит их. Но зашифровать-то измененный файл он обратно не сможет! У него же нет приватного ключа!

А зачем ему Ваш приватный ключ ??? Он своим будет шифровать.

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

D>А зачем ему Ваш приватный ключ ??? Он своим будет шифровать.

вот и я об этом... ))