Комментарии 29
Спасибо, очень полезная статья, было бы здорово добавить абзац с краткими выводами для людей без юридического образования, с примерами.
Скажем «Если зарегистрировать свой домен и хостить почту у Яндекса, при соблюдении таких и таких условий для организации и для физического лица — документы в электронном виде (не)будут иметь юридическую силу»
Скажем «Если зарегистрировать свой домен и хостить почту у Яндекса, при соблюдении таких и таких условий для организации и для физического лица — документы в электронном виде (не)будут иметь юридическую силу»
Хорошо бы, если бы ЭЦП была уникальна, как ИНН, СНИЛС, св. о рождении. И всегда можно было бы сказать когда ЭЦП была примена, кем и какой документ. То есть через удостоверяющий центр, всегда можно было проверить эту подпись. Может блокчейн какой или нечто подобное.
Это как с лампочками. Сейчас вы каждый год покупаете новую подпись. Иначе, столько денег мимо уйдёт! ;)
Лучше каждый год покупать, чем та фигня, что с телефонами сейчас творится.
Теще регулярно приходят сообщения с 900 номера о поступлении пенсии какой-то левой бабушке. Насколько я понимаю, это значит, что бабуля забросила свой номер, и теперь теща технически может между поступлением и снятием пенсии перенаправить деньги на свои нужды одной SMSкой, а сбер скажет бабуле, что она сама подтвердила перевод.
Но идея блокчейна использования ЭЦП с хешом документа, что был подписан это забавно. Но опять таки, кажется не решает вопроса времени компрометации ЭЦП. И добавляет проблем с централизацией. Это валюту народ майнит, а подписи то не станут. Значит либо чейн станет централизованным, и его можно выкинуть и заменить на БД удостоверяющего центра, или надо как-то поощрять материально участников его формирования.
Теще регулярно приходят сообщения с 900 номера о поступлении пенсии какой-то левой бабушке. Насколько я понимаю, это значит, что бабуля забросила свой номер, и теперь теща технически может между поступлением и снятием пенсии перенаправить деньги на свои нужды одной SMSкой, а сбер скажет бабуле, что она сама подтвердила перевод.
Но идея блокчейна использования ЭЦП с хешом документа, что был подписан это забавно. Но опять таки, кажется не решает вопроса времени компрометации ЭЦП. И добавляет проблем с централизацией. Это валюту народ майнит, а подписи то не станут. Значит либо чейн станет централизованным, и его можно выкинуть и заменить на БД удостоверяющего центра, или надо как-то поощрять материально участников его формирования.
Уж лучше блокчейн, даже если его блоки будет делать только одна госконтора. БД почему-то имеют тенденцию незаметно изменяться задним числом.
Эм, то есть блокчейн для ЭЦП не такая уж и плохая идея? Я просто практически пальцем в небо ткнул.
ЭЦП — это только схема. У Вас есть закрытый асимметричный ключ, вы шифруете им хеш документа и публикуете свой открытый ключ и результат шифрования — это и есть ЭЦП. Кто угодно может проверить, что: а) документ подписывали именно Вы; б) Вы подписывали именно этот документ. Причем отозвать подпись нельзя.
Блокчейн — это способ упорядочивания блоков: в каждом блоке хранится хеш предыдущего, а потому никакие изменения «задним числом» провести нельзя.
Проблема ЭЦП именно в удостоверении, что данный асимметричный ключ принадлежит именно Васе, а не черт знает кому. Для этого нужно третье лицо (удостоверяющий центр), которое опубликует юридически значимую запись: обладателем указанного ключа является Вася. Методом публикования может быть и блокчейн.
Если надо отслеживать именно само применение ЭЦП, то тогда надо просто договориться считать валидной только ЭЦП, опубликованную в составе очередного блока.
Блокчейн — это способ упорядочивания блоков: в каждом блоке хранится хеш предыдущего, а потому никакие изменения «задним числом» провести нельзя.
Проблема ЭЦП именно в удостоверении, что данный асимметричный ключ принадлежит именно Васе, а не черт знает кому. Для этого нужно третье лицо (удостоверяющий центр), которое опубликует юридически значимую запись: обладателем указанного ключа является Вася. Методом публикования может быть и блокчейн.
Если надо отслеживать именно само применение ЭЦП, то тогда надо просто договориться считать валидной только ЭЦП, опубликованную в составе очередного блока.
Я так понимаю сейчас удостоверяющие центры генерируют обе части ключа, получается у них есть копии и подписи не очень личные.
да, формально УЦ не имеют права хранить закрытый ключ, но наказания пока нет (вроде как есть поправки с 01.01.2017). Можете сгенерировать запрос на ЭП сами и принести его в УЦ, тогда у них закрытого ключа 100% не будет…
Ключевая пара (открытый ключ и закрытый ключ) должны генерироваться на стороне пользователя. В УЦ отправляется запрос на сертификат. Запрос содержит открытый ключ и подписывается соответствующим ему закрытым ключом (тем самым подтверждается подлинность владения ключевой парой). На основании этого запроса УЦ выпускает сертификат, который устанавливает связь между ключевой парой и конкретным лицом.
могут, а не должны. УЦ может сгенерить его за вас. Обязательств генерить ключи только на стороне пользователя в законе нет.
А при продлении есть УЦ которые дают не только самому сгенерировать первоначальную подпись, но и потом подписывают продление удалённо?
Удалённое продление (или перевыпуск сертификата) — это традиционная возможность, предоставляемая УЦ.
В этом случае вы отправляете уже не самоподписанный запрос, а подписываете запрос закрытым ключом с действующим сертификатом. По истечении срока действия сертификата такая процедура невозможна.
В этом случае вы отправляете уже не самоподписанный запрос, а подписываете запрос закрытым ключом с действующим сертификатом. По истечении срока действия сертификата такая процедура невозможна.
Вы не правы. Запрос на сертификат (имею в виду издание нового сертификата — «по-вашему» продление) всегда подписывается ключом электронной подписи, который соответствует ключу проверки электронной подписи в теле запроса! Это важно! По электронной подписи запроса на издание сертификата УЦ убеждается в наличии у клиента соответствующего ключа электронной подписи.
Действующим же ключом электронной подписи (с действующим сертификатом) клиент может, в зависимости от правил взаимодействия с конкретным УЦ, либо установить SSL-соединение с УЦ, либо подписать электронный документ типа «подписанное сообщение», содержащее запрос на издание сертификата.
Соответствие терминов из 63ФЗ с «простонародными»:
1) электронная подпись (ЭП) — ЭЦП, ЦП и т.д.;
2) ключ электронной подписи — закрытый ключ, секретный ключ;
3) ключ проверки электронной подписи — открытый ключ.
Действующим же ключом электронной подписи (с действующим сертификатом) клиент может, в зависимости от правил взаимодействия с конкретным УЦ, либо установить SSL-соединение с УЦ, либо подписать электронный документ типа «подписанное сообщение», содержащее запрос на издание сертификата.
Соответствие терминов из 63ФЗ с «простонародными»:
1) электронная подпись (ЭП) — ЭЦП, ЦП и т.д.;
2) ключ электронной подписи — закрытый ключ, секретный ключ;
3) ключ проверки электронной подписи — открытый ключ.
Вы правы во всём, кроме того, что я не прав. Я недостаточно точно и подробно выразился, из-за чего был неправильно понят.
Мой комментарий следует читать так:
Хотел бы добавить к соответствию терминов, что в англоязычной среде разница между ЭП-ЭЦП-ЦП более явная, чем у нас. Так, электронная подпись (electronic signature) — более общий термин, включающий любые данные в электронном виде, логически связанные с другими данными в электронном виде и использующиеся подписантом для подписи (например, биометрические данные), в то время как цифровая подпись (digital signature) — более узкий и являющийся подмножеством электронной подписи термин, означающий подпись, созданную с помощью криптографии.
Мой комментарий следует читать так:
В этом случае вы отправляете уже не самоподписанный запрос, а подписываете <самоподписанный> запрос закрытым ключом с действующим сертификатом.Это как раз ваш второй вариант (подписание нового самоподписанного запроса закрытым ключом с действующим сертификатом и отправка полученной PKCS#7-структуры). Безусловно, никто не выпускает сертификат когда открытый ключ подписи запроса не соответствует закрытому ключу (что является тонким намёком на прочтение слово самоподписанный между строк, но никак не умоляет моих грехов). Механизм подписи уже подписанного запроса широко используется (например, в КриптоПро УЦ как одобрение на выпуск сертификата оператором).
Хотел бы добавить к соответствию терминов, что в англоязычной среде разница между ЭП-ЭЦП-ЦП более явная, чем у нас. Так, электронная подпись (electronic signature) — более общий термин, включающий любые данные в электронном виде, логически связанные с другими данными в электронном виде и использующиеся подписантом для подписи (например, биометрические данные), в то время как цифровая подпись (digital signature) — более узкий и являющийся подмножеством электронной подписи термин, означающий подпись, созданную с помощью криптографии.
Я специально конкретизировал, что термины согласно 63ФЗ, а не англоязычной среде.
Мое пожелание Вам: «Чтобы не случалось казусов с непониманием, выражайтесь как можно более точно, иначе „новички“ могут неправильно понять и еще более неправильно истолковать со своих слов. Особенно в сфере криптографии. Удачи.»
Мое пожелание Вам: «Чтобы не случалось казусов с непониманием, выражайтесь как можно более точно, иначе „новички“ могут неправильно понять и еще более неправильно истолковать со своих слов. Особенно в сфере криптографии. Удачи.»
Термин «сторона пользователя» в законе не определён. В моём понимании это личный токен, доступ к ключам которого имеет только пользователь. Можно придти с ним в УЦ и сгенерировать ключи там, но системы УЦ доступа к закрытому ключу иметь не должны, т.к. статьи 9 и 10 федерального закона №63-ФЗ гласят:
Получение доступа к закрытому ключу третьими лицами (в том числе самим УЦ) является нарушением конфиденциальности.
Статья 9. Использование простой электронной подписи
…
2. Нормативные правовые акты и (или) соглашения между участниками электронного взаимодействия, устанавливающие случаи признания электронных документов, подписанных простой электронной подписью, равнозначными документам на бумажных носителях, подписанным собственноручной подписью, должны предусматривать, в частности:
…
2) обязанность лица, создающего и (или) использующего ключ простой электронной подписи, соблюдать его конфиденциальность.
…
Статья 10. Обязанности участников электронного взаимодействия при использовании усиленных электронных подписей
При использовании усиленных электронных подписей участники электронного взаимодействия обязаны:
1) обеспечивать конфиденциальность ключей электронных подписей, в частности не допускать использование принадлежащих им ключей электронных подписей без их согласия;
…
3) не использовать ключ электронной подписи при наличии оснований полагать, что конфиденциальность данного ключа нарушена;
Получение доступа к закрытому ключу третьими лицами (в том числе самим УЦ) является нарушением конфиденциальности.
Мои глаза… В терминологии ПЭП, словами «электронная подпись» и «закрытый ключ» называются вещи, которые не являются ни электронными подписями, ни закрытыми ключами. Никакой пароль к почте или к чему там не может называться термином «закрытый ключ», никакой логин — термином «открытый ключ», а факт получения документа с доверенного email адреса не может называться «электронной подписью».
И ещё, судя по статье, ФЗ вообще не умеет регулировать криптографические системы, в которых участник идентифицируется чем-то иным, кроме паспортных данных? Например, просто публичным ключом?
И ещё, судя по статье, ФЗ вообще не умеет регулировать криптографические системы, в которых участник идентифицируется чем-то иным, кроме паспортных данных? Например, просто публичным ключом?
по поводу 2 абзаца, вы не совсем правы. на основании соглашений вы может вообще все что угодно и как угодно, но до тех пор пока вы не хотите пойти, например в суд, и тут вылезает:
«Простой электронной подписью является электронная подпись, которая посредством использования кодов, паролей или иных средств подтверждает факт формирования электронной подписи определенным лицом». определить лицо вы можете посредством удостоверения личности, коим в РФ является паспорт, военник и пр (там список внушительный) у ним НЕ относятся:
— водительские права
— СНИЛС
Так что да, для суда только паспорт, никаких публичных ключей.
Хотя, вы можете предоставить сертификат, в котором есть публичный ключ и ваше ФИО + СНИЛС, но это уже не простая, а усиленная подпись. И паспорт вы все равно предъявляете в УЦ.
«Простой электронной подписью является электронная подпись, которая посредством использования кодов, паролей или иных средств подтверждает факт формирования электронной подписи определенным лицом». определить лицо вы можете посредством удостоверения личности, коим в РФ является паспорт, военник и пр (там список внушительный) у ним НЕ относятся:
— водительские права
— СНИЛС
Так что да, для суда только паспорт, никаких публичных ключей.
Хотя, вы можете предоставить сертификат, в котором есть публичный ключ и ваше ФИО + СНИЛС, но это уже не простая, а усиленная подпись. И паспорт вы все равно предъявляете в УЦ.
В статье, видимо, не хватает раздела о терминологии, так как на разных языках диалога не получится. Необходимо общее понимание, что такое электронная подпись (ЭП), что такое электронно-цифровая подпись (ЭЦП), и что такое простая электронная подпись (ПЭП). И чем ЭЦП отличается от ПЭП. Ваш комментарий целиком и полностью относится к ЭЦП. ЭЦП и ПЭП — это абсолютно разные сущности, и различаются они как раз тем, что в случае ЭЦП используется криптография, а в случае ПЭП — криптография НЕ используется. ФЗ знает и об криптографии, и о публичных ключах, и умеет их регулировать. Но статья совсем не об этом.
Кстати говоря, проблема терминологии носит исторический характер. В России было два закона об электронной подписи. В законе 2002 года не было других видов электронных подписей, кроме как ЭЦП. И очень многие считают, что понятие электронной подписи ограничивается криптографией и ЭЦП. Но закон 2011 года расширил понятие электронной подписи и вообще выбросил такое понятие, как ЭЦП. Его там нет. Оно заменено другими понятиями, а именно: электронная подпись без применения криптографии, которая в законе называется простой электронной подписью, и электронная подпись с применением криптографии, которая имеет две разновидности: неквалифицированная электронная подпись и квалифицированная электронная подпись.
Кстати говоря, проблема терминологии носит исторический характер. В России было два закона об электронной подписи. В законе 2002 года не было других видов электронных подписей, кроме как ЭЦП. И очень многие считают, что понятие электронной подписи ограничивается криптографией и ЭЦП. Но закон 2011 года расширил понятие электронной подписи и вообще выбросил такое понятие, как ЭЦП. Его там нет. Оно заменено другими понятиями, а именно: электронная подпись без применения криптографии, которая в законе называется простой электронной подписью, и электронная подпись с применением криптографии, которая имеет две разновидности: неквалифицированная электронная подпись и квалифицированная электронная подпись.
ПЭП в 63ФЗ «сунули» законотворцы — регуляторы (ФСБ) были изначально против ее. На различных конференциях посвященных развитию ИОК в РФ (в частности, «PKI-форум Россия 2010») они «рекомендовали» не использовать ее даже в корпоративных ЭДО. Но на их рекомендации «бизнес и некоторые госучреждения» возмущались. Поэтому, чтобы хоть как то навести порядок с применением ПЭП, «регуляторы» при участии Минкомсвязь решили организовать применение ПЭП через единый «портал», в котором будут регистрироваться «специальные параметры» ПЭП… Только вот чем это закончилось, мне не известно…
Автору небольшое уточнение, фраза:
«Если нет интеграции с ЕСИА или интеграции с государственной информационной системой межведомственного электронного взаимодействия (СМЭВ), электронные сервисы которой позволяют сопоставить СНИЛС или серийный номер паспорта с фамилией и именем, то удаленно получить юридически значимую ПЭП довольно трудоемко»
не совсем корректна. Во-первых, не получив доступа к СМЭВ вы не получите доступа к ЕСИА (со стороны информационной системы. а не пользователя), поэтому там не «или», а «и».
во-вторых. ни один сервис не возвращает вам информацию о номера вашего паспорта и ФИО. Сервис МВД возвращает только информацию о том отозван паспорт или нет. Сопоставление паспорт-имя-снилс происходит когда вы приходите в МФЦ и там у вас все проверяют и регистрируют (просто небольшое уточнение функционала). интересный вопрос, надо ли идти снова после смены паспорта если смену делал не через ЕСИА, а путем прихода ножками в УВД...(сам менять пойду еще не скоро:))) Так что для ЕСИА основным идентификатором является все же снилс
Ну и третье. коммерческой организации получить доступ к ЕСИА невозможно, а потому ПЭП+ЕСИА никому особо и не надо т.к. там у всех давно уже получена усиленная квалифицированная электронная подпись…
«Если нет интеграции с ЕСИА или интеграции с государственной информационной системой межведомственного электронного взаимодействия (СМЭВ), электронные сервисы которой позволяют сопоставить СНИЛС или серийный номер паспорта с фамилией и именем, то удаленно получить юридически значимую ПЭП довольно трудоемко»
не совсем корректна. Во-первых, не получив доступа к СМЭВ вы не получите доступа к ЕСИА (со стороны информационной системы. а не пользователя), поэтому там не «или», а «и».
во-вторых. ни один сервис не возвращает вам информацию о номера вашего паспорта и ФИО. Сервис МВД возвращает только информацию о том отозван паспорт или нет. Сопоставление паспорт-имя-снилс происходит когда вы приходите в МФЦ и там у вас все проверяют и регистрируют (просто небольшое уточнение функционала). интересный вопрос, надо ли идти снова после смены паспорта если смену делал не через ЕСИА, а путем прихода ножками в УВД...(сам менять пойду еще не скоро:))) Так что для ЕСИА основным идентификатором является все же снилс
Ну и третье. коммерческой организации получить доступ к ЕСИА невозможно, а потому ПЭП+ЕСИА никому особо и не надо т.к. там у всех давно уже получена усиленная квалифицированная электронная подпись…
Да, согласен, основным идентификатором является СНИЛС, так как он удобен для электронной обработки, но этот факт пока не зафиксирован на законодательном уровне. Для действующего закона основой для идентификации личности является документ, содержащий фотографию, фамилию и имя, поэтому, до принятия соответствующего закона, в явном или неявном виде должна быть связка СНИЛС + удостоверение личности. Кстати, если не ошибаюсь, в СМЭВ сервис ПФР позволяет проверить связку СНИЛС+паспорт.
Есть некоторые признаки, что электронные взаимоотношения с физическими лицами будут двигаться в сторону увеличения удобства использования ПЭП+ЕСИА, а ЭЦП, квалифицированную или неквалифицированную, оставят для юридических лиц. Об этом говорят ряд законопроектов, внесенных Минкомсвязи на рассмотрение Правительства. Я считаю, что это правильно. Если подобрать исторические аналогии, то ЭЦП — это фактически документ с печатью, а заставлять каждое физическое лицо получать печать не совсем логично. У физического лица есть собственноручная подпись, при переходе на электронный документооборот не должно сильно что-то поменяться. А инфраструктура открытых ключей, которая нужна для ЭЦП, все же сложна для простых граждан.
Также согласен, чтобы связка ПЭП+ЕСИА полноценно заработала, нужно открыть доступ коммерческим организациям к ЕСИА. Такой законопроект сейчас внесен на рассмотрение Правительства, правда и доступ предусматривается сделать коммерческим.
Ознакомиться со всеми планируемыми изменениями в ЕСИА можно на портале проектов нормативных актов: Проекты нормативных актов
Есть некоторые признаки, что электронные взаимоотношения с физическими лицами будут двигаться в сторону увеличения удобства использования ПЭП+ЕСИА, а ЭЦП, квалифицированную или неквалифицированную, оставят для юридических лиц. Об этом говорят ряд законопроектов, внесенных Минкомсвязи на рассмотрение Правительства. Я считаю, что это правильно. Если подобрать исторические аналогии, то ЭЦП — это фактически документ с печатью, а заставлять каждое физическое лицо получать печать не совсем логично. У физического лица есть собственноручная подпись, при переходе на электронный документооборот не должно сильно что-то поменяться. А инфраструктура открытых ключей, которая нужна для ЭЦП, все же сложна для простых граждан.
Также согласен, чтобы связка ПЭП+ЕСИА полноценно заработала, нужно открыть доступ коммерческим организациям к ЕСИА. Такой законопроект сейчас внесен на рассмотрение Правительства, правда и доступ предусматривается сделать коммерческим.
Ознакомиться со всеми планируемыми изменениями в ЕСИА можно на портале проектов нормативных актов: Проекты нормативных актов
Юридически значимой такая ПЭП будет при выполнении следующих условий:
Соглашением установлена однозначная, и не допускающая толкований, связь публичной части ключа ПЭП(логина) с УЛ пользователя учетной записи;
Закрытая часть ключа ПЭП строго конфиденциальна и это зафиксировано в соглашении;
А ведь этих условий явно недостаточно для соответствия требованию 63-ФЗ к ПЭП: "… подтверждает факт формирования электронной подписи определенным лицом". Все упирается в то, что ни пользователь, ни регулирующие органы не могут быть уверены в добросовестности серверной стороны.
При онлайн-взаимодействии для обеспечения соответствия ПЭП требованиям закона потребуется подтверждение того, что программное обеспечение сервера, отвечающее за взаимодействие с пользователем, как минимум,
- Гарантирует отсутствие доступа до ввода правильного пароля.
- Гарантирует невозможность перехвата пароля средствами, неподконтрольными пользователю.
- Гарантирует невозможность имитации действий пользователя на стороне сервера.
- Гарантирует корректное протоколирование параметров сеанса и значимых действий пользователя.
- Гарантирует невозможность фальсификации протоколов.
Без этого все «соглашения о признании», составленные юридическиподобным языком, будут не более, чем филькиной грамотой, поскольку невозможно достоверно подтвердить «факт формирования подписи определенным лицом».
Системы с уникальными кодами, пересылаемыми в SMS, тоже должны гарантировать, что направленный пользователю код был затем действительно передан с его стороны, а не подставлен сервером самостоятельно. Причем не только передан со стороны, пользователя, но и введен им в окно браузера извне, а не подставлен браузером, предварительно получившим код от сервера.
Гарантировать все перечисленное может, понятное дело, только сертифицированное программное обеспечение. Возможно, ЕСИА и прошла необходимый аудит, но то, что его прошло ПО всех интернет-банков и сайтов, предлагающих заключить «Соглашение о...», весьма сомнительно.
Другим способом обеспечения гарантий могла бы быть фиксация каким-либо способом версии работающего на сервере ПО вместе с его исходниками (тут уже не обойтись без криптографии и доверенных сертификатов с метками времени). Тогда на момент взаимодействия какие-либо гарантии отсутствуют, но в случае возникновения споров можно потребовать проведения аудита ПО.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Подводные камни» простой электронной подписи