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