Comments 51
А можно я уточню вот какой момент. Сейчас область действия сертификата ограничивается перечнем OID. Получается, сейчас будет один сквозной список ?
Состав полей сертификата определяется 63-фз и приказом #795 ФСБ. Есть понятие ограничений сертификата ( например сертификат может быть использован только для авторизации), но понятия область действия нет. Это скорее всего самодеятельность УЦ, с которой и борются правки.
Что касается oid, их ведение давно централизовано, и есть международный орган который ведет единое дерево OID ( oid-info.com). В России орган отвечающий за ведение национального дерева oid не определен. Пока его ведет инфотекс.
Что касается oid, их ведение давно централизовано, и есть международный орган который ведет единое дерево OID ( oid-info.com). В России орган отвечающий за ведение национального дерева oid не определен. Пока его ведет инфотекс.
Гриш, статья хорошая, но буквосочетания, понятные только узкому кругу изьранных типа «ИС ГУЦ» — это прям вот жесть.
Особенно порадовал п.4)) Много хороших идей было разбито об этот «камень») Спасибо за ваш очерк.
Что несут свежие изменения
Как обычно, ничего хорошего.
Это наконец то можно будет купить одну ЭЦП, а не 3 — для каналов отчетности, для электронных торгов, для документов? А еще ж ЭЦП для списка заблокированных сайтов :) Осталось еще банки подтянуть и забыть про россыпь ЭЦП на столе.
Банки используют такую же ЭП как и все остальные участники пространства доверия. Указанное изменение должно коснуться и интернет банкинга.
Но это породит и новую проблему — использование одной ЭП и для аутентификации и для подписи документов.
Но это породит и новую проблему — использование одной ЭП и для аутентификации и для подписи документов.
С точки зрения пользователя — один токен с ключем становится дороже чем "ключи от квартиры, где деньги лежат". Потерял эту "свистульку" вместе с ПИНом — разденут до нитки и еще какую-нибудь уголовку заведут.
Ну и нечего ПИН вместе с ЭЦП хранить. Это все равно что ПИН на кредитке подписывать, а потом руками разводить-да как же так-то?
Люди, к сожалению, совершают ошибки, и мое мнение — надо создать инфраструктуру PMI в дополнение к PKI, чтобы потеря ключа с пином не стала равносильна смерти владельца :)
Это в стране эльфов все пин знают наизусть и никому не говорят. В реальном мире все иначе.
Вы абсолютно правы, по этому, в скором времени появится такой объект как "Атрибутный сертификат", и я надеюсь нормальная инфраструктура PMI для этого.
По сути это замена печати и хранят их обычно в сейфе.
По-моему, это уже классическая схема: сначала делаем так, чтобы через прикормленные компаниях отбить затраты на разработку и внедрение ПО.
Потом, через 2-3 года, вносим правки, чтобы работало так, как и предполагалось.
Увидите, с онлайн ККТ будет то же самое.
Потом, через 2-3 года, вносим правки, чтобы работало так, как и предполагалось.
Увидите, с онлайн ККТ будет то же самое.
Ну то есть, как обычно, какую-никакую свободу и самостоятельность заменили пришедшим "сверху" дрыном зависимости от единого центра — и "ура, всё будет совместимо"? Далеко там ещё осталось до единого разрешенного центра выдачи SSL-сертификатов, подписанных сертификатом ФСБ ?
Свободу и самостоятельность никто у вас не планирует забирать. Свой сертификат для SSL вы можете взять откуда угодно, никто не в праве вас ограничить. Использовать сертификат выпущенный российским УЦ пока не получится именно из-за чехарды с пространством доверия. Как только ФСБ сертифицирует ГОСТы в ISO и их поддержка появится во всех системах по умолчанию, использование для SSL сертификата выданного российским УЦ будет не лишено смысла.
вы мне скажите пожалуйста: есть хоть какой-то шанс того, что это всё не только под виндой с корявыми дровами будет работать, а всё таки и с линуксом/маком?
Там вроде стандартный PKI, так что проблем быть не должно. slay2000, Гриш, подтверди плз.
То есть, сотрудникам ГУЦ теперь будет легче подделывать сертификаты? Очень полезно и удобно, не сомневаюсь!
Вам часто подделывали паспорт в полиции? Не каждый сотрудник ГУЦ имеет право пользоваться ключом ЭП ГУЦ, да и класс защищенности от НСД к техническим средствам ГУЦ в целом и к ключам ЭП в частности на порядок (даже на несколько порядков) выше, чем у рядового УЦ.
Часто или не часто, это просто обычная уязвимость, когда твой приватный ключ знает кто-то еще, он уже не приватный.
После генерации в ГУЦ приватный ключ АУЦ находится в HSM, откуда его извлечь нельзя. Вам это поможет?
Я должен вам или гуц на слово поверить о происхождении ключа?
Никто Вам, как сертифицированному УЦ, не мешает создать, средствами сертифицированного СКЗИ, ключевую пару ЭП, сформировать запрос на издание сертификата (в него входит только ключ проверки ЭП), подписать запрос сформированным ключом ЭП и отправить этот запрос (тем или иным разрешенным способом) в ГУЦ, чтобы тот издал сертификат ключа проверки ЭП вашего УЦ. Не вижу проблем, нужно лишь придерживаться формата запроса, поддерживаемого ГУЦ.
З.Ы.: продолжая занудства, начатые в предыдущем моем комментарии, скажу: «В нашем мире нужно кому-то верить — всегда должен быть корень доверия. Именно для этого и придумана ИОК (инфраструктура открытых ключей), где УЦ — третья доверенная сторона, которой все доверяют!»
З.Ы.З.Ы.: полиции, выдавшей Вам паспорт, Вы верите же, что это она (полиция) законно и качественно его (паспорт) сделала, а не купила на «черном рынке».
З.Ы.: продолжая занудства, начатые в предыдущем моем комментарии, скажу: «В нашем мире нужно кому-то верить — всегда должен быть корень доверия. Именно для этого и придумана ИОК (инфраструктура открытых ключей), где УЦ — третья доверенная сторона, которой все доверяют!»
З.Ы.З.Ы.: полиции, выдавшей Вам паспорт, Вы верите же, что это она (полиция) законно и качественно его (паспорт) сделала, а не купила на «черном рынке».
А не трудно быть "впереди планеты всей" по количеству УЦов — "… уже аккредитованные УЦ которых около 300 в РФ..."? Бред да и только! Нормировка на цифровую процессинговую потребность в сигнатуре на душу населения как-то уже обсуждалась на PKI форуме в Питере — около 15, но правильных ( !) где корешок под HSM'ом… и пр
И еще, кроме приказа №795 есть еще и №796 — требования к средствам ЭП, где ясно прописаны требования безопасности к средствам ДОСТУПА к контейнеру ключевого материала, что однозначно влечет выполнение условий в механизмах протоколов АУТЕНТИФИКАЦИИ, а вот декларирования их по-прежнему и нет. Вроде в ТК26 как-то это обсуждалось под HMAC-OTP. Короче, вся эта лабуда ввиде припарок к 63-ФЗ пахнет тухлятиной если еще принять во внимание мобильную среду и т.н. облачные сервисы, где нужны схемы типа Server-Side-Signature ( SSS), там вроде как народ из Крипто-ПРО, Демос и пр как-то что-то предлагали. Реализация этого возможна ТОЛЬКО на HSM порталах. Так что, конструкторам из минсвязи и их советникам-экспертам флаг в руки по ЭП-строительству в РФ:-)
И еще, кроме приказа №795 есть еще и №796 — требования к средствам ЭП, где ясно прописаны требования безопасности к средствам ДОСТУПА к контейнеру ключевого материала, что однозначно влечет выполнение условий в механизмах протоколов АУТЕНТИФИКАЦИИ, а вот декларирования их по-прежнему и нет. Вроде в ТК26 как-то это обсуждалось под HMAC-OTP. Короче, вся эта лабуда ввиде припарок к 63-ФЗ пахнет тухлятиной если еще принять во внимание мобильную среду и т.н. облачные сервисы, где нужны схемы типа Server-Side-Signature ( SSS), там вроде как народ из Крипто-ПРО, Демос и пр как-то что-то предлагали. Реализация этого возможна ТОЛЬКО на HSM порталах. Так что, конструкторам из минсвязи и их советникам-экспертам флаг в руки по ЭП-строительству в РФ:-)
У меня жена бухгалтер в бюджетном учреждении. Самое интересное в том, где они берут эту электронную подпись — ее им выдают в казначействе! То есть приватный ключ уже вовсе не приватный, а подпись — это вовсе не подпись, а чистая профанация.
Потому что большая часть операций в госучреждениях проводится через казначейство. Я вот работал в небюджетном(автономном) госучреждении — большинство операций проходило через казначейство и ключи были от них. Для небольшой части других операций — брались в какой-то из частных контор. занимающихся ключами в городе.
Да, я понимаю, что они просто реализовали цифровую подпись, распилив кучку бюджетных денег, при этом совершенно не задумываясь о смысле. Кстати, можно было воспользоваться абсолютно бесплатным софтом вместо того, чтобы изобретать свой велосипед, но цель видимо была именно в распиле. Но смысл цифровой подписи в итоге был утрачен практически полностью ибо в оригинале он сводился к тому, что
После того, как основной принцип цифровой подписи извратили до неузнаваемости, смысла в ней почти не осталось, разве что усложняет жизнь бухгалтерии.
- подпись шифруется приватным ключем
- приватный ключ генерируется самим пользователем, в этом смысл его приватности и это обеспечивает основное свойство подписи — невозможность подделки
- публичный ключ аннонсируется пользователем и регистрируется УЦ
После того, как основной принцип цифровой подписи извратили до неузнаваемости, смысла в ней почти не осталось, разве что усложняет жизнь бухгалтерии.
«подпись шифруется приватным ключем»
Неверное утверждение с точки зрения специалиста, но «сойдет» с точки зрения обывателя! Вы либо путаете понятие подпись (не могу предположить какая) с ЭП, либо просто неверно истолковали определение ЭП из ФЗ или Википедии, не вдаваясь криптографические основы ЭП. Проще говоря, ЭП — это результат криптографического преобразования значения ХЭШ-функции (тоже криптографическое преобразование и это не «подпись») подписываемого документа с использованием ключа ЭП (нет понятия «приватный ключ» согласно ФЗ «Об ЭП»).
Неверное утверждение с точки зрения специалиста, но «сойдет» с точки зрения обывателя! Вы либо путаете понятие подпись (не могу предположить какая) с ЭП, либо просто неверно истолковали определение ЭП из ФЗ или Википедии, не вдаваясь криптографические основы ЭП. Проще говоря, ЭП — это результат криптографического преобразования значения ХЭШ-функции (тоже криптографическое преобразование и это не «подпись») подписываемого документа с использованием ключа ЭП (нет понятия «приватный ключ» согласно ФЗ «Об ЭП»).
Спасибо, что указали мне на первоисточник этой извращенной трактовки ЭП. Действительно, в самом ФЗ написано, что УЦ генерирует ключ электронной подписи, а вовсе не ее владелец. Скажите мне, как специалист по шифрованию, что мы можем сказать об умственных способностях автора этого документа?
Давайте представим себе, что вместо личной подписи вы используете простой штампик, который вам выдали в райотделе милиции вместе с паспортом. Что можно сказать про документ, проштампованный этим штампом? Ну видимо то, что его держал в руках человек, у которого есть такой штамп. Это могли быть вы, а могли и не вы, а человек из того же райотдела или любой другой, имеющий точную копию вашего штампика. Смысл электронной подписи в том, что владелец изготавливает ее сам.
Давайте представим себе, что вместо личной подписи вы используете простой штампик, который вам выдали в райотделе милиции вместе с паспортом. Что можно сказать про документ, проштампованный этим штампом? Ну видимо то, что его держал в руках человек, у которого есть такой штамп. Это могли быть вы, а могли и не вы, а человек из того же райотдела или любой другой, имеющий точную копию вашего штампика. Смысл электронной подписи в том, что владелец изготавливает ее сам.
Про умственные способности автора этого документа ничего не хочу говорить… Ибо, как водится, авторов этих на разных уровнях разработки-согласования предостаточно и тут уже срабатывает принцип «испорченного телефона».
Насколько мне известно (хотя могу и ошибаться, приняв свою логичную точку зрения за истину) в ФЗ говорится, что УЦ должен иметь функцию формирования пользовательских ключей ЭП, но не обязан это делать для всех пользователей (нет там понятия «обязан»). Например, отдельный пользователь может приобрести сертифицированные средства ЭП, зарегистрироваться в УЦ (при регистрации пользователя УЦ может сформировать ключевую пару ЭП и издать сертификат с ограничениями области действия «только для аутентификации») и далее самому сформировать ключ ЭП и отправить запрос в УЦ на издание сертификата ключа проверки ЭП с «нормальными ограничениями области действия». А тот факт, что некоторые организации, предоставляющие функции УЦ, навязывают оговоренный вами «неправильный» способ формирования ключей ЭП и издание сертификатов «на УЦ», так это их личная прихоть (на мой взгляд), с которой вы соглашаетесь подписывая договор на оказание услуг УЦ. В том же договоре есть пункты, гласящие, что УЦ обязуется сохранять в тайне Ваши ключи ЭП и несет ответственность за их компрометацию, если Вы докажете, что компрометация была по вине УЦ. И, наверное повторюсь, УЦ в инфраструктуре ИОК (PKI) является «доверенной для всех участников» стороной. Если Вы не доверяете ЭП другого участника, то Вы не доверяете и УЦ.
И еще одно небольшое замечание — для использования личного ключа ЭП необходимо пройти процедуру аутентификации (по паролю, токену и т.д.).
З.Ы.: на моей практике разработки, внедрения и эксплуатации УЦ на предприятии могу заявить, что основной причиной компрометации ключей ЭП являются сами пользователи — ну не умеют и не хотят они адекватно относиться к ключам ЭП (стирают с носителей ключевые контейнеры: 1) «какой-то непонятный каталожек на халявной флешке»; 2) «стер, потому что фильм не влазил» и т.д.)
Насколько мне известно (хотя могу и ошибаться, приняв свою логичную точку зрения за истину) в ФЗ говорится, что УЦ должен иметь функцию формирования пользовательских ключей ЭП, но не обязан это делать для всех пользователей (нет там понятия «обязан»). Например, отдельный пользователь может приобрести сертифицированные средства ЭП, зарегистрироваться в УЦ (при регистрации пользователя УЦ может сформировать ключевую пару ЭП и издать сертификат с ограничениями области действия «только для аутентификации») и далее самому сформировать ключ ЭП и отправить запрос в УЦ на издание сертификата ключа проверки ЭП с «нормальными ограничениями области действия». А тот факт, что некоторые организации, предоставляющие функции УЦ, навязывают оговоренный вами «неправильный» способ формирования ключей ЭП и издание сертификатов «на УЦ», так это их личная прихоть (на мой взгляд), с которой вы соглашаетесь подписывая договор на оказание услуг УЦ. В том же договоре есть пункты, гласящие, что УЦ обязуется сохранять в тайне Ваши ключи ЭП и несет ответственность за их компрометацию, если Вы докажете, что компрометация была по вине УЦ. И, наверное повторюсь, УЦ в инфраструктуре ИОК (PKI) является «доверенной для всех участников» стороной. Если Вы не доверяете ЭП другого участника, то Вы не доверяете и УЦ.
И еще одно небольшое замечание — для использования личного ключа ЭП необходимо пройти процедуру аутентификации (по паролю, токену и т.д.).
З.Ы.: на моей практике разработки, внедрения и эксплуатации УЦ на предприятии могу заявить, что основной причиной компрометации ключей ЭП являются сами пользователи — ну не умеют и не хотят они адекватно относиться к ключам ЭП (стирают с носителей ключевые контейнеры: 1) «какой-то непонятный каталожек на халявной флешке»; 2) «стер, потому что фильм не влазил» и т.д.)
Если правильно понял, то делают один гос УЦ, а остальные станут подчиненными.
Зачем генерировать ключевую пару на каком-то ГУЦ? Почему этот ГУЦ не может просто подписать сертификаты тех УЦ, которые он считает правильными? Если у пользователя сертификат ГУЦ в доверенных, то и те УЦ, сертификаты, которых он подписал, тоже доверенные.
Через несколько лет мы получим полную зависимость от единой точки — ГУЦ. Компрометация единственного УЦ приведет к полному краху всей модели доверия. Такого рода централизация мне не нравится.
Децентрализация удостоверяющих центров это не детская болезнь, а принятая модель доверия в инфраструктурах с открытым ключом. Я был бы крайне недоволен, если завтра, например, США скажут, что все WebTrust УЦ должны получать корневые ключи от USA_ROOT_CA, а не генерировать их самостоятельно.
Зачем генерировать ключевую пару на каком-то ГУЦ? Почему этот ГУЦ не может просто подписать сертификаты тех УЦ, которые он считает правильными? Если у пользователя сертификат ГУЦ в доверенных, то и те УЦ, сертификаты, которых он подписал, тоже доверенные.
В итоге через несколько лет мы получим единое и связное пространство доверия, в котором пользователи смогут чувствовать себя комфортно и использовать свои российские сертификаты для своих интернет-страничек, что в настоящее время не возможно.
Через несколько лет мы получим полную зависимость от единой точки — ГУЦ. Компрометация единственного УЦ приведет к полному краху всей модели доверия. Такого рода централизация мне не нравится.
Скажу честно, я доволен работой МКС по развитию пространства доверия, которое перерастает детские болезни в области использования ЭП в России, давно пора.
Децентрализация удостоверяющих центров это не детская болезнь, а принятая модель доверия в инфраструктурах с открытым ключом. Я был бы крайне недоволен, если завтра, например, США скажут, что все WebTrust УЦ должны получать корневые ключи от USA_ROOT_CA, а не генерировать их самостоятельно.
> Ведомствам издателям сертификатов теперь ЗАПРЕЩЕНО вносить с сертификаты дополнительные поля и требования их обязательности
Хотел уже было поругаться с Росреестром, который не принимает мою ЭЦП из за отсутствия в ней соответствующего OID-а, однако, более детальное изучение закона подсказало, что этот запрет вступает в силу только 08.07.2016…
Хотел уже было поругаться с Росреестром, который не принимает мою ЭЦП из за отсутствия в ней соответствующего OID-а, однако, более детальное изучение закона подсказало, что этот запрет вступает в силу только 08.07.2016…
Вот уже конец 2016го а чтото моя эцп для гос торгов не пашет более нигде кроме торгов, или я что-то не так понял.
Sign up to leave a comment.
Что несут свежие изменения в 63-ФЗ «об электронной подписи»