зашифровал файл, сохранил его на диске. Затем успешно дешифровал и прочитал. Все работает на "ура", но есть проблемы.
Ключи создаются так:
CspParameters keyParams = new CspParameters( );
keyParams.KeyContainerName = "Имя_хранилища";
RSACryptoServiceProvider provider = new RSACryptoServiceProvider( keyParams );
Что такое "Имя_хранилища"? Где оно находится?
Ещё я могу сохранять ключи вот так
RSACryptoServiceProvider RSA = new RSACryptoServiceProvider( );
RSA.ToXmlString( true );
А потом читать их:
RSA.FromXmlString( someString );
А эта строка в открытом виде хранится на диске.
Хорошо ли это? Или это проблема пользователя хранить её в недоступном месте, чтобы никто файл не читал?
Здравствуйте, Spender, Вы писали:
S>Привет, Всем.
S>Я с помощью S>
S>RSACryptoServiceProvider
S>
S>зашифровал файл, сохранил его на диске. Затем успешно дешифровал и прочитал. Все работает на "ура", но есть проблемы.
S>Ключи создаются так: S>
S>CspParameters keyParams = new CspParameters( );
S>keyParams.KeyContainerName = "Имя_хранилища";
S>RSACryptoServiceProvider provider = new RSACryptoServiceProvider( keyParams );
S>
S>Что такое "Имя_хранилища"? Где оно находится?
Они хранятся в защищенном контейнере предоставляемом криптосервиспровайдером, в данном случае — RSACryptoServiceProvider-ом. Это в принципе хорошее место для хранения ключей. Но в случае с RSACryptoServiceProvider-ом есть один подвох. Ключи хранятся персонально для каждого пользователя и если запустить этот код от имени другого пользователя то получить ранее сохраненный ключ не получится (вылетает exception). Причем флаг CspProviderFlags.UseMachineKeyStore не помогает в этом случае. Не знаю баг это или фича, но к этому надо быть готовым (актуально для Framework 1.1).
Физически ключи хранятся на диске в профайле пользователя в каталоге Application Data\Microsoft\Crypto\RSA в файлах с гремучими названиями в виде гуидов и очень ограниченными NTFS пермишенами. Желательно их руками не трогать, там есть ключи которые использует IIS и еще бог знает кто...
Здравствуйте, stump, Вы писали:
S>Здравствуйте, Spender, Вы писали:
S>>Привет, Всем.
S>Физически ключи хранятся на диске в профайле пользователя в каталоге Application Data\Microsoft\Crypto\RSA в файлах с гремучими названиями в виде гуидов и очень ограниченными NTFS пермишенами. Желательно их руками не трогать, там есть ключи которые использует IIS и еще бог знает кто...
Получается, зная имя хранилища, я могу получить доступ к ключам, если запущу прогу из под определенного пользователя? Не хорошо, как-то =)
Здравствуйте, Pavel M., Вы писали:
PM>Здравствуйте, stump, Вы писали:
S>>Здравствуйте, Spender, Вы писали:
S>>>Привет, Всем.
S>>Физически ключи хранятся на диске в профайле пользователя в каталоге Application Data\Microsoft\Crypto\RSA в файлах с гремучими названиями в виде гуидов и очень ограниченными NTFS пермишенами. Желательно их руками не трогать, там есть ключи которые использует IIS и еще бог знает кто...
PM>Получается, зная имя хранилища, я могу получить доступ к ключам, если запущу прогу из под определенного пользователя? Не хорошо, как-то =)
То то и оно, что надо знать не только имя контейнера но и имя и пароль пользователя.
Здравствуйте, stump, Вы писали:
S>Здравствуйте, Pavel M., Вы писали:
PM>>Получается, зная имя хранилища, я могу получить доступ к ключам, если запущу прогу из под определенного пользователя? Не хорошо, как-то =)
S>То то и оно, что надо знать не только имя контейнера но и имя и пароль пользователя.
Взглянем со стороны злоумышленника =) Можно не знать имя пользователя и пароль, но найти уязвимость ПО,позволяющую уже запущенному приложению запустить ПО злоумышленника.
А права доступа к папке с ключами и самому можно настроить!
Здравствуйте, Pavel M., Вы писали:
PM>Здравствуйте, stump, Вы писали:
S>>Здравствуйте, Pavel M., Вы писали:
PM>>>Получается, зная имя хранилища, я могу получить доступ к ключам, если запущу прогу из под определенного пользователя? Не хорошо, как-то =)
S>>То то и оно, что надо знать не только имя контейнера но и имя и пароль пользователя.
PM>Взглянем со стороны злоумышленника =) Можно не знать имя пользователя и пароль, но найти уязвимость ПО,позволяющую уже запущенному приложению запустить ПО злоумышленника.
Но это будет не наша уязвимость.
PM>А права доступа к папке с ключами и самому можно настроить!
Когда мы рассуждаем о безопасности, всегда надо понимать где следует остановиться чтобы не впасть в паранойю. Все о чем ты говоришь, лежит уже за пределами нашей системы. Мы просто принимаем допущение, что система работает в безопасном окружении. Чтобы сменить права доступа к той папке где лежат контейнеры криптопровайдера, надо обладать правами админа. Не существует защиты от злоумышленника с правами админа!
Здравствуйте, stump, Вы писали:
S>Здравствуйте, Pavel M., Вы писали:
S>Когда мы рассуждаем о безопасности, всегда надо понимать где следует остановиться чтобы не впасть в паранойю. Все о чем ты говоришь, лежит уже за пределами нашей системы. Мы просто принимаем допущение, что система работает в безопасном окружении. Чтобы сменить права доступа к той папке где лежат контейнеры криптопровайдера, надо обладать правами админа. Не существует защиты от злоумышленника с правами админа!
Я говорю о том, что человек, увидевший в моем ПО дыру, может попробовать запустить приложение с правами, с которыми запущено мое приложение и получить доступ к хранилищу =) А если я отвечаю за развертку приложения и разработку системы безопасности, а также за предварительную настройку сервера, то и за потерю денег и информации буду отвечать я, хотя бы частично =))) Так что параноя уместна! =)))
Здравствуйте, Pavel M., Вы писали:
PM>Я говорю о том, что человек, увидевший в моем ПО дыру, может попробовать запустить приложение с правами, с которыми запущено мое приложение и получить доступ к хранилищу =) А если я отвечаю за развертку приложения и разработку системы безопасности, а также за предварительную настройку сервера, то и за потерю денег и информации буду отвечать я, хотя бы частично =))) Так что параноя уместна! =)))
А я говорю что контейнер криптопровайдера — это надежное хранилище для ключа.
Можно например не хранить имя контейнера в коде приложения а попросить ввести его пользователю при первом запуске приложения а потом зашифровать паролем пользователя и хранить зашифрованным.
На это можно ответить что если злоумышленник узнает пароль пользовател.... Или можно снять дамп во время работы приложения и вычислить расшифрованное имя контейнера. И так до бесконечности.
>> Причем флаг CspProviderFlags.UseMachineKeyStore не помогает в этом случае. Не знаю баг это или фича Не баг. Если этот флаг установлен, то, как и обещано, контейнер создастся не в персональном \..\RSA, а в общем \All Users\..\MachineKeys.
Исключение, которое при этом все-таки возникает объясняется отсутствием прав доступа к контейнеру у нового пользователя. Установите для него Read(как минимум) permission на файл контейнера.
>> Причем флаг CspProviderFlags.UseMachineKeyStore не помогает в этом случае. Не знаю баг это или фича
Не баг. Если этот флаг установлен, то, как и обещано, контейнер создастся не в персональном \..\RSA, а в общем \All Users\..\MachineKeys.
Исключение, которое при этом все-таки возникает объясняется отсутствием прав доступа к контейнеру у нового пользователя. Установите для него Read(как минимум) permission на файл контейнера.
Как оказалось, старый добрый Aspnet_regiis -pa .. это и делает.
>> Взглянем со стороны злоумышленника =) Можно не знать имя пользователя и пароль, но найти уязвимость ПО,позволяющую уже запущенному приложению запустить ПО злоумышленника.
Тогда вас должно успокоить наличие Smart Cards, USB-tokens и Crypto Accelerators.
