> Это все замечательно, но доступность информации также > является частью задачи обеспечения ИБ. > Внеплановая смена ключа - очень @#$овая процедура. Я раньше > тоже относился с непониманием к депонированию ключей, пока > электронный документооборот с ЭЦП не стал частью > повседневной жизни. Например, запустил я документ на > согласование, поставил подпись, понадобились правки, а у > меня ключ сменился. Во-первых я просто напросто уже никогда > не смогу прочитать документ, который отправитель зашифровал > на моем открытом ключе, т.к. для этого мне нужен мой > секретный, а он помер вместе с токеном. в случае использования шифрования, я бы применял key recovery module и проблемы с чтением сообщений, была бы решена. Хотя конечно там могут быть грабли, которых я пока не вижу.
> Во-вторых, в > системе должна решаться задача сопоставления разных ключей > одной сущности (должностному лицу), а это очень > нетривиально, поверь человеку, который такую систему > внедрял, подводные грабли на каждом шагу закопаны. > Короче, ключики ЭЦП депонировать надо, но не > централизовано, а каждому индивидуально, на дискету и в > личный сейф. Не даром в PKCS#11 предусмотрена функция > загрузки внешнего ключа в токен (но при этом совершенно > правильно отсутствует функция выгрузки ключа из токена). > Не спорю, депонирование ключей ЭЦП имеет смысл. Но средний пользователь с этим не справится. Просто не справится. В силу того что ему, что наши токены, что ключи... до одного места, а не которые из-за неспособности воспринять.
Да и не у всех есть сейфы :)
> p.s. Поигрался еще со смарт-картами SETEC, тоже > замечательно работают. На подходе Cryptoflex от > Schlumberger, будем сравнивать, что дешевле и с более > богатым софтом.
Генерация ключей Microsoft CA и безопасность получения и назначение сертификатов17.09.04 07:40 Автор: pilikonis Статус: Незарегистрированный пользователь
Установлен Windows server 2003 enterprise edition. Поднят Stand-Alone root CA. Запрос на генерацию ключей идет через http://servername/certsrv. Подскажите где сохраняются сгенерированные ключи, если они не помечены, как экспортируемые, при использовании стандартных криптопровайдеров? Что нужно сделать, кроме разрешения экспортирования, чтобы они сохранялись сразу на е-токен или смарт-карту и не оставались на жестком диске и какие настройки на сервере необходимо сделать для этого?
> http://servername/certsrv. Подскажите где сохраняются > сгенерированные ключи, если они не помечены, как > экспортируемые, при использовании стандартных > криптопровайдеров? Что нужно сделать, кроме разрешения Стандартные криптопровайдеры хранят ключи в реестре.
> экспортирования, чтобы они сохранялись сразу на е-токен или > смарт-карту и не оставались на жестком диске и какие > настройки на сервере необходимо сделать для этого? А не проще при генерации использовать криптопровайдер смарт-карты, тогда секретный ключ будет сгенерен ее процессором и вообще в комп никогда не попадет?
При установленном RTE от е-токена оно замечательно генерится прямо на карте.
Если же генерил станщдартным провайдером, токенговской же утилитой импортируй ключ/сертификат в токен с удалением секретного ключа из реестра. и все будет в ажуре.
p.s. при последнем варианте, я бы копию ключа еще на дискету сохранил, и в сейф ее. на всякий случай - вдруг токен накроется?
А какой смысл на дискету копию делать? ИМХО в этом то и есть...21.09.04 17:22 Автор: yeoman Статус: Незарегистрированный пользователь
> p.s. при последнем варианте, я бы копию ключа еще на > дискету сохранил, и в сейф ее. на всякий случай - вдруг > токен накроется?
А какой смысл на дискету копию делать? ИМХО в этом то и есть основная прелесть такого носителя, ключи никогда не покидают носитель и существуют в единственном варианте ( по крайней мере я думаю это справедливо для ключей подписи). Если уж токен приказал долго жить, то можно взять новый, создать новую пару и т.д.
Это все замечательно, но доступность информации также...28.09.04 08:59 Автор: cybervlad <cybervlad> Статус: Elderman
> А какой смысл на дискету копию делать? ИМХО в этом то и > есть основная прелесть такого носителя, ключи никогда не > покидают носитель и существуют в единственном варианте ( по > крайней мере я думаю это справедливо для ключей подписи). > Если уж токен приказал долго жить, то можно взять новый, > создать новую пару и т.д. Это все замечательно, но доступность информации также является частью задачи обеспечения ИБ.
Внеплановая смена ключа - очень @#$овая процедура. Я раньше тоже относился с непониманием к депонированию ключей, пока электронный документооборот с ЭЦП не стал частью повседневной жизни. Например, запустил я документ на согласование, поставил подпись, понадобились правки, а у меня ключ сменился. Во-первых я просто напросто уже никогда не смогу прочитать документ, который отправитель зашифровал на моем открытом ключе, т.к. для этого мне нужен мой секретный, а он помер вместе с токеном. Во-вторых, в системе должна решаться задача сопоставления разных ключей одной сущности (должностному лицу), а это очень нетривиально, поверь человеку, который такую систему внедрял, подводные грабли на каждом шагу закопаны.
Короче, ключики ЭЦП депонировать надо, но не централизовано, а каждому индивидуально, на дискету и в личный сейф. Не даром в PKCS#11 предусмотрена функция загрузки внешнего ключа в токен (но при этом совершенно правильно отсутствует функция выгрузки ключа из токена).
p.s. Поигрался еще со смарт-картами SETEC, тоже замечательно работают. На подходе Cryptoflex от Schlumberger, будем сравнивать, что дешевле и с более богатым софтом.
в случае использования шифрования, я бы применял key...29.09.04 16:22 Автор: yeoman Статус: Незарегистрированный пользователь
> Это все замечательно, но доступность информации также > является частью задачи обеспечения ИБ. > Внеплановая смена ключа - очень @#$овая процедура. Я раньше > тоже относился с непониманием к депонированию ключей, пока > электронный документооборот с ЭЦП не стал частью > повседневной жизни. Например, запустил я документ на > согласование, поставил подпись, понадобились правки, а у > меня ключ сменился. Во-первых я просто напросто уже никогда > не смогу прочитать документ, который отправитель зашифровал > на моем открытом ключе, т.к. для этого мне нужен мой > секретный, а он помер вместе с токеном. в случае использования шифрования, я бы применял key recovery module и проблемы с чтением сообщений, была бы решена. Хотя конечно там могут быть грабли, которых я пока не вижу.
> Во-вторых, в > системе должна решаться задача сопоставления разных ключей > одной сущности (должностному лицу), а это очень > нетривиально, поверь человеку, который такую систему > внедрял, подводные грабли на каждом шагу закопаны. > Короче, ключики ЭЦП депонировать надо, но не > централизовано, а каждому индивидуально, на дискету и в > личный сейф. Не даром в PKCS#11 предусмотрена функция > загрузки внешнего ключа в токен (но при этом совершенно > правильно отсутствует функция выгрузки ключа из токена). > Не спорю, депонирование ключей ЭЦП имеет смысл. Но средний пользователь с этим не справится. Просто не справится. В силу того что ему, что наши токены, что ключи... до одного места, а не которые из-за неспособности воспринять.
Да и не у всех есть сейфы :)
> p.s. Поигрался еще со смарт-картами SETEC, тоже > замечательно работают. На подходе Cryptoflex от > Schlumberger, будем сравнивать, что дешевле и с более > богатым софтом.
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
