| ||||
| ||||
| Скажите пожалуйста, возможно ли в качестве носителей ключей использовать жесткий диск (файл). Ведь насколько я понял, носителями могу выступать реестр, дисковод, таблетки Touch-Memory и т.д. А возможно ли ключи записывать в файл на диски и при шифрации\дешифрации считывать их из этого фала? спасибо. | ||||
| Ответы: | ||||
| ||||
| Нет. Во всяком случае, на Win. Для UNIX (Solaris 9, FreeBSD 5, RedHat 9) и CSP 3.0 - можно. | ||||
| ||||
| Почему нельзя? А экспорт/импорт? | ||||
| ||||
| Игорь, конечно, Вы правы. Но! Экспорт сессионного ключа (а также ключевой пары) возможен только на ключе Диффи-Хеллмана (который делается с помощью ключа из контейнера, а как раз контейнер-то человек и не хотел использовать). | ||||
| ||||
| >>"а как раз контейнер-то человек и не хотел использовать". Вы правы. Но получается экспорт ключевой пары можно сделать всегда, имея контейнер. Допустим. Но на др. стороне надо делать импорт, и опять в реестр?! получается как то убоговато все время с реестром работать) в экселенсе можно было с файлами -контейнерами работать... кому то это было необходимо... | ||||
| ||||
| > Но получается экспорт ключевой пары можно сделать всегда, имея контейнер Экспорт можно сделать только если он разрешён (когда при создании контейнера был указан соответствующий флажок). Далее. Приведите конкретные аргументы в пользу того, почему (и кому) неудобно хранить ключ в ключевом контейнере. И вообще, странно получается - данные зашифрованы, а ключ - вот он, в файле, рядом лежит, любой расшифровать может. А если не любой имеет доступ к файлу с ключом (т.е. либо пароль на открытие, либо аутентификация и проверка прав, либо съёмный носитель) - то чем это будет принципиально отличаться от контейнера ключа? | ||||
| ||||
| Да, дополню ещё. Импорт сессионного ключа из блоба делается не в реестр, а в оперативную память (приложения или сервиса). При закрытии контекста контейнера информации о сессионном ключе в контейнере не останется. | ||||
| ||||
| >>>>Приведите конкретные аргументы в пользу того, почему (и кому) неудобно хранить ключ в ключевом контейнере. наверное не смогу ответить вразумительно... Но у старших программистов, узнавших о том, что нельзя хранить контейнер в в отдельном файле, волосы поднялись дыбом..) На сервере хранится около сотни контейнеров. Имеется порядочное количество фирм (порядка 15-30). В старом варианте (когда была возможность работы с файлами-контейнерами) файлы - контейнеры распихивались по папкам фирм: каждой фирме - свои ключи. Поэтому выбор нужного ключа для шифрации\дешифрации из приложения можно было легко выбрать (просто выбрав нужную папку и ключ). Подразумевалось, что пользователь одной фирмы, не будет пользоваться ключами из папки другой фирмы. Видимо, всё на доверии. А при работе с реестром, такой четкой структуры пользователь не получает. Приходится вводить имя контейнера и аттрибуты сертификата (например, искать по CERT_FIND_SUBJECT_STR)... В принципе, всё это единичный случай, но всё таки...) | ||||
| ||||
| Тут есть хитрость. Которая облегчит Вам жизнь. Можно хранить в файле не сам закрытый ключ, а сертификат открытого ключа. Тогда хендл контейнера получаем из контекста сертификата, открытого из файла. Естественно, предварительно, сертификат устанавливается (с привязкой к секретному ключу) в хранилище Личные того пользователя, который имеет право расшифровывать информацию из этой папки. Ну, или жить под одним аккаунтом пользователя для всех папок, контейнеров и сертификатов. | ||||
| ||||
| >>>"Можно хранить в файле не сам закрытый ключ, а сертификат открытого ключа. Тогда хендл контейнера получаем из контекста сертификата, открытого из файла." Интересно. Получаем хендл сертификата из файла, и шифруем/дешифруем. А закрытые ключи используются из контейнера( в реестре), к которуме привязан сертификат. Так выходит? | ||||
| ||||
| Да. Только ключевой контейнер не обязан быть в реестре. | ||||
| ||||
| СПАСИБО большое!!!!!!! | ||||
zebra