22 июня 2015 в 03:32

Будущее электронной подписи


Электронная подпись является проверенным, надежным и, что немаловажно, юридически признанным способом подтверждения авторства и целостности документа. Но, к сожалению, пользователям не всегда удобно работать с ключами и сертификатами. Попробуйте вставить смарт-карту в iPad или смартфон. Конечно, производители придумывают всякие ухищрения вроде смарт-карт в форм-факторе microSD или Bluetooth токенов. Но и это не всегда соответствует ожиданиям пользователя.

Я бы хотел рассказать о более удобном способе электронной подписи.

Что же можно сделать


Конечно, электронная подпись невозможна без сертификата. Но нужно ли пользователю владеть лично своими ключами, чтобы их использовать и, например, подписывать документы? Большинство специалистов по информационной безопасности ответят, что ключи обязательно должны быть у пользователя и только так он может произвести подпись. До недавнего времени я бы и сам так сказал, пока не столкнулся с классом продуктов, предоставляющих облачную подпись. Да, слово «облачный» настолько избито маркетологами, что я, например, всегда очень скептически воспринимаю информацию, где оно встречается. Однако тут трудно придумать что-то другое.

Сервер облачной подписи сам осуществляет все необходимые действия. От пользователя нужно только дать необходимые указания. Ну и самое главное, что должен сделать пользователь – аутентифицироваться.

Очевидным плюсом такого подхода является перенос Secure Element от пользователей, которые не очень-то приспособлены для правильного хранения и использования всяких смарт-картами, на сервер. Вот на сервере-то ключевая информация может храниться под защитой HSM. Это само по себе, не сильно отличается от хранения ключей на смарт-карте или токене. Но, согласитесь, научить всех пользователей правильно хранить ключевую информацию намного сложнее, чем обеспечить должный уровень безопасности сервера подписи. К тому же современные HSM из коробки предоставляют неплохие возможности для правильной работы с ключевой информацией.

Вопрос аутентификации пользователя становится в данном случае очень остро. Тут без многофакторной аутентификации не обойтись. На сегодняшний день уже есть большой выбор методов строгой аутентификации, таких, как, например, одноразовые пароли или биометрия. При должной настройке строгая аутентификация предоставляет уровень доверия к пользователю не ниже, чем при самостоятельном предъявлении сертификата.

На практике


Представьте, что пользователю нужно подписать документ своей цифровой подписью. Пользователь аутентифицируется на сервере подписи, предоставляя свой логин, пароль и одноразовый код. Затем пользователь просто отправляет документ, который хочет подписать, а удаленный сервер все делает сам. Документ подписан сертификатом (на самом деле, конечно, закрытым ключом) этого пользователя.

Почему так лучше


Чтобы развеять сомнения, нужно только ответить себе на один вопрос: зачем нужна электронная подпись? А нужна она для того, чтобы быть уверенным, что она поставлена владельцем и чтобы обеспечить целостность. Первое успешно достигается многофакторной аутентификацией. Неплохие примеры ее использования – работа с интернет-банком. Целостность, конечно, тоже обеспечивается благодаря той самой подписи, которую ставит сервер.

Пользователи становятся более мобильными и перестают производить всевозможные генерации ключей и обновления сертификатов. Упрощается определение отозванных сертификатов. Не требуется дополнительная простановка штампа времени. В общем, одни плюсы.

Что-то похожее уже было


Аналогичный процесс с вынесением Secure Element в облако сейчас наблюдается в области электронных платежей. Технология Host Card Emulation позволяет эмулировать платежную карту на смартфоне без привязки к Secure Element, как это было раньше. Secure Element переносится в облако банка или, так называемого, Token Service Provider. Такой подход значительно упрощает развитие мобильных платежей и избавляет от необходимости построения отношений доверия между производителями смартфонов и банками.
Николай Корабельников @nmk2002
карма
14,5
рейтинг 0,1
Информационная безопасность
Самое читаемое Разработка

Комментарии (41)

  • +4
    Глядя на то, как обращаются с ЭП люди, я порой задаюсь вопросом: а не параноик ли я? Может, так и надо? Выдавать ключи и сертификаты в открытом виде на флешке (в лучшем случае, в архиве с паролем). Писать пин-коды на токенах, или оставлять дефолтный 1234. Может, ну их нафиг, эти токены, кому они вообще нужны? Хранить все в реестре! Понапридумывали тут, понимаешь, сложностей. Подписи какие-то, компьютеры, ключи электронные, бабки плати каждый год… Отметки времени еще какие-то, кому они нужны? Вот в кадастровой палате просто выдали сотрудникам сертификаты до 2027 года, зачем заморачиваться с перевыпуском? (а до этого были обычные, сроком на год, поэтому документы росреестра, подписанные в тот период, уже юридически не признать. Кстати, был период, когда они выдавали документы, подписанные просроченной подписью. Где-то месяц.)
    Надо быть проще! еще проще! Чтоб самый тупой пользователь смог все подписать, а дальше гори огнём!
    Все-таки я, наверное, параноик…
    • 0
      Абсолютно с вами согласен, но:
      1. грамотность пользователей в области ЭП растет на глазах, и это снимает ряд проблем поднятых вами;
      2. банки демонстрируют возможности совершения операций без ЭП, используя многофакторную идентификацию;
      3. государство само еще не готово к работе с ЭП, тот пример с сертификатами до 2027 года — наглядное тому подтверждение.

      Я думаю, мы только в начале пути: на нас сейчас отрабатывают эту технологию, поэтому и складывается впечатление абсурда. Совсем недавно трудно было понять смысл слова «Электронное правительство», теперь это вполне понятные государственные и муниципальные электронные услуги. Но, несмотря на весь прогресс в этой области, существует огромный пласт технических проблем. В качестве примера, приведу, поднятый вами случай: что делать с электронными документами, подписанными уже просроченным сертификатом (ключом). Сейчас они считаются недействительными, то есть у документа есть срок жизни. Представьте себе свидетельство о рождении, которое каждый год надо продлять. Вместе с тем, в Японии каждый совершеннолетний гражданин имел собственную печать еще во времена, когда компьютеров не было. Зачем, когда можно обойтись подписью — спросите вы. Другая культура — другие понятия. Вот и сейчас мы на переломе, когда жить по-старому уже нельзя, а по-новому не получается.
      • 0
        Чтоб ты жил в эпоху перемен!, — говаривали хитрые китайцы.
      • +2
        Если на момент подписи сертификат просроченный, то подпись действительно должна быть невалидная.
        Если же на момент подписи сертификат был валидным, то подпись тоже должна успешно проходить проверку даже после истечения срока жизни сертификата. Для этого используется штамп времени.
        • +3
          Для этого нужно доплатить денюжку фирме крипто-про, да и просто знать про эту технологию. Росреестр, увы, или не слышал о таком достижении, или бюрократия не позволила.
          Я склоняюсь к версии о тотальной некомпетентности на всех уровнях этого гос.учреждения.
          • 0
            Вот представьте себе: вы ничего не знаете о криптографии, тут вам приходит грозная бумажка — с завтрашнего дня обеспечить электронную подпись документов. Причем, ни финансирования, ни методических указаний, под этой бумажкой нет. Что делать? Обратиться за помощью в какую-нибудь контору, которая в этом хоть что-то понимает. Из предложенных этой конторой вариантов будет выбран вариант с наименьшими финансовыми вложениями, так как эти деньги отрываются от запланированных ранее затрат. Так что можно говорить не о компетентности какого-то госучреждения в каком-то вопросе, а о непрофессиональности государственного управления.
            • +1
              По поводу того, что нет финансирования — позволю себе не согласиться. На электронные штучки росреестра тратятся огромные деньги (как всегда). Некоторые крупные функционеры даже бегут из страны в связи с этим.
              Впрочем, то, что вы описали — это моя мысль другими словами. Непрофессиональность = некомпетентность.

              Результат один.
              • 0
                Извините, что неправильно выразился. Федеральные министерства и ведомства возможно и имеют огромные средства для выполнения всех своих эротических фантазий, но почему-то вниз спускают не деньги и конкретные инструкции, а приказы. Так вот, в этой связи глупо обвинять системного администратора или специалиста по работе с клиентами, что они не понимают как надо работать с ЭП.
                • +1
                  Да ладно! росреестр — это и есть федеральная структура. Сапельников сбежал в США как раз в связи с информатизацией — публичная карта и т.п. Там на эту программу, емнип, несколько десятков миллиардов потрачено было (еще до отчета счетной палаты, а когда выяснилось, что денежки тютю — еще дали). И свои отдельные подразделения по информатизации там, и люди зарплату получают регулярно,
                  А по поводу обвинений простых сотрудников — так это очень напоминает ситуацию на почте, тоже, казалось бы, простые люди не виноваты, на мизерную зарплату специалисты не идут, денег нет и т.п. Так я их и не обвиняю особо, к тому же мое исключительно личное мнение (о некомпетентности) основывается не только на эпизодах с просроченной ЭЦП.
                  Как вам, например, публикация новых ХМL схем через месяц после вступления их в силу? ну и так далее.
                  Это не ядерная физика, просто обычное, банальнейшее раздолбайство, пофигизм и отрицательный отбор. На всех уровнях.
            • 0
              Спокойно представляю:
              У каждой бумажки кроме подписи начальника есть подпись — исполнитель. Я звоню исполнителю с вопросом: WTF?
              Он говорит — обратитесь туда. Обращаюсь, узнаю цены — делаю передвижку или запрос дополнительных финансовых средств.
              • 0
                То есть, вместо закупки бумаги или бензина, приобретается криптосредство. А бумагу потом возьмем в кредит, в следующем году оплатим, а в следующем году придет еще одна бумага, мы опять отвлечем средства и так по кругу.
                • 0
                  Нормальный экономист всегда заложит резерв.
  • +10
    Главная проблема для такого сервиса — доверие к самому сервису. Никто не мешает владельцу сервиса подписать произвольный документ от имени произвольного пользователя.
    • –1
      Конечно, надо доверять сервису. Так же как надо доверять УЦ. И много кому еще приходится доверять.
      Вы же доверяете софту, который фактически осуществляет подпись используя ваши ключи в классическом варианте. Причем, я почти уверен, что вы даже не проверяете, что подписываете. Ведь реально подписывается хэш файла.
      Тогда в чем различие доверия к сервису, осуществляющего подпись и доверия к софту делающему то же самое?
      • 0
        Всё таки, когда приватный ключ лежит у меня под замком, спиться куда крепче.
  • 0
    И именно поэтому действительно и по-настоящему защищенной системой может считаться только система с «нулевым» доверием. Все прочие, включая и описываемую в статье — всего лишь симулякры…
  • +4
    Возможно для кого-то такая вот «облачная подпись» является будущим электронных подписей. Для меня же перенос всех приватных ключей пользователей на сервер означает примерно то же самое, как если бы все обычный человек передал право подписывания всех документов нотариусу. Всех, включая договора, обязательства, отказы от имущественных прав и так далее. Будущее? Я против подобного будущего.
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Это не будущее ЭП, это её настоящее.
  • +5
    То есть Вы предлагаете передавать свой персональный закрытый ключ, который используется для подписи в юридически значимом документообороте какой-то третьей, пусть и доверенной (условно), стороне? Вы действительно считаете, что сервер с какой-то многофакторной аутентификацией надежнее клиентских персональное устройств?

    Если у пользователя возникают проблемы с наипросторнейшей процедурой подключения токена или смарт-карты, вводом PINа и непосредственно подписью, то стоит ли вообще его наделять правом подписи?

    Да, использование ЭП требует от пользователя соблюдения определенных правил, но это не повод добровольно отказаться от своего закрытого ключа в угоду кажущегося удобства.

    • –3
      А то, что сегодня вы передаете закрытый ключ смарт-карте вас не пугает? А что там за софт на смарт-карте? Что за закладки? Не считаете ли вы, что таким образом вы уже отказались от своего закрытого ключа?
      А еще вы доверяете какому-то стороннему софту делать что угодно с ключевой информацией на этой смарт-карте. Вас это тоже не пугает?

      Для меня то, что вы пишете звучит как: «Коробка автомат? Да вы что? Как можно доверять переключение передач какой-то сторонней системе? Водители должны сами все контролировать!»
      • 0
        До недавнего времени я и не подозревал, что пользуюсь электронной подписью, когда оплачиваю сотовую связь через интернет-банк, пока не увидел «Простая электронная подпись Ким Н.Г. от 31.12.9999» в платёжном поручении. Здесь код подтверждения в SMS является частью реализации облачной ЭП, о которой говорится в статье. Это удобно и, доверяя своему банку, я этим пользуюсь.

        Тем не менее, смарт-карту, даже полную закладок, я хотя бы могу взять в руки и таким образом контролировать физическое местонахождение ключей, а организовав воздушный зазор — полагать, что они случайно не попадут в чужие руки во время использования.
      • +2
        Я не считаю себя конченным параноиком и не испытываю дискомфорта от того, что мой закрытый ключ хранится на токене. Хотя, по понятным причинам, и это устройство нельзя считать абсолютно безопасным. Однако согласитесь, персональное устройство, подключаемое по требованию, вызывает бОльшее доверие, чем общедоступный сервис (пусть даже в рамках доверенной сети) с хранилищем всех закрытых ключей пользователей, к которому в любой момент времени может получить доступ любой пользователь.

        И знаете, я вполне доверяю и автоматам, и роботам и бесступенчатым трансмиссиям. Более того, я предпочитаю автоматы. Но переключение скоростей и передача стороннему сервису права подписи документов — для меня совершенно разные вещи.

        Если же Вы не видите разницы, то что ж… Имеете на то право.

        • 0
          И мистер Сноуден тому подтверждение.
        • –2
          Не важно общедоступен ли сервис или предоставляется только вам. Ключи в решении с облачной подписью должны храниться на HSM. Никто, даже сам сервер подписи, не получает сами закрытые ключи.

          Безопасность типа «подключение по требованию» перестает работать в тот самый момент, когда вы подключаете смарт-карту.

          Вы рассуждаете с точки зрения технически подкованного потенциального пользователя. На практике большая часть пользователей систем, требующих ЭП, не очень поддаются внушению и обучению в части правил хранения и эксплуатации смарт-карт.
          С точки зрения владельца сервиса, требующего ЭП, пользователи от которых требуется самостоятельно хранить и использовать ключи на смарт-картах это бОльшая проблема, чем пользователи от которых требуется только проверка подлинности.

          По поводу АКПП: возможно, неудачная аналогия.
          Но, продолжая транспортные аналогии: вы же доверите свою безопасность пилоту самолета, а не предпочтете научиться управлять самостоятельно.
          Конечно аналогия гипертрофированна, но я просто пытаюсь передать смысл:
          Разумный человек захочет сам отвечать за свою безопасность только если он действительно способен это сделать.

          Вопрос доверия — дело личное. Каждый сам должен определять кому, что и в какой ситуации доверять. Хорошо, что вы подходите к этому с таким уровнем ответственности.
          • 0
            > Никто, даже сам сервер подписи, не получает сами закрытые ключи.

            ОК, допустим, что ключи генерируются самим сервером прямо в HSM и про их содержимое он действительно ничего не знает.

            Но зато он прекрасно знает содержимое всех конфиденциальных документов, отправляемых ему на подпись, и может выпустить свой похожий документ от вашего имени, если его хозяевам вдруг так захочется или его кто-то поимеет.

            Оно вам таки действительно надо?
            • –1
              Ну конечно содержимое подписываемых документов недоступно серверу подписи. Для подписи нужен только хэш. Процесс создания подписи сопровождается логом, который хранится в БД с защитой целостности.
          • 0
            Ключи в решении с облачной подписью должны храниться на HSM. Никто, даже сам сервер подписи, не получает сами закрытые ключи.

            Во всей этой «облачной» архитектуре устройство HSM — единственное, чему я могу доверять. Гораздо больше вопросов возникает с механизмами аутентификации (как облачный сервис решает, что именно я владелец закрытого ключа), с передачей документов третьему лицу и т.д. Все эти «лишние» шаги способствуют дополнительным проблемам. И уж коли Вы так любите транспортные аналогии, то мне подобные сервисы видятся не как пилот-профессионал за штурвалом боинга, а как таксист-гастарбайтер за рулем ушатанной шестерки. Если кого-то устраивает такой сервис — пожалуйста.

            Вопрос доверия — дело личное.

            Вот тут Вы правы. И я такой системе довериться не могу.
            • 0
              Механизмы аутентификации могут быть любыми. И от их выбора будет зависеть вероятность несанкционированного использования вашей ЭП.
              Задача передачи документов не является задачей сервера подписи. Он документы не хранит, а только подписывает. А хранится документы могут, например в СЭД. Вот он то и решает задачу их передачи.

              К сожалению почти любую системы можно превратить в ушатанную шестерку. Хороший пример — тот же PKI. Мало где в организациях он развернут по правилам. Администратор просто ставит MSCA и делает, что считает нужным. А ведь PKI — это по большей части регламенты/правила/инструкции. Примеры, когда разертывание PKI сопроваждалось написанием Certificate Policy/Certificate Practice Statement, организацией ключевой церемонии (Key Ceremony) с привлечением внешних аудиторов можно в РФ пересчитать по пальцам.

              Тем не менее, организации, предоставляющей сервисы технически проще правильно настроить и эксплуатировать одну сущность, чем отвечать за всех пользователей.
              У нас почему-то чаще решается вопрос с ответственностью, чем вопрос с потенциальными рисками. Можно конечно собрать со всех пользователей расписки с обязательствами делать то-то и не делать то-то с ключевым носителем. Но в случае с нарушением этих правил, пострадать может и организация предоставляющая сервис.
              Если у вас 10000 пользователей, то я бы предпочел возить их на боинге, а не раздавать всем по кукурузнику в надежде, что они усвоили правила пользования.
  • –1
    А не пойти ли таким умным облакам в лес!?
    Может в лесу найдутся дураки.

    Там много громких слов: «сертификат», «смарт карта» — это всё так сложно, ага.
    «Конечно, электронная подпись невозможна без сертификата.» — нуда нуда.

    Сертификат это просто контейнер для хранения ххх бит случайных данных, которые и являются секретным ключём.
    Подписывание это вычисление хэша того что мы подписываем, потом скармливание его и секретного ключа в функцию которая генерирует подпись.
    Проверяющая сторона вычисляет хэш и скармливает его и публичный ключ (получается из секретного) в другую функцию, которая выдаёт да или нет.

    Вот и вся сложная схема.
    Даже центры сертификации тут не обязательны.
    Центры сертификации просто хранят публичные ключи и ручаются своей репутацией за их подлинность.
    • –1
      Следуя вашей логике: нотариусы тоже не нужны, они просто заверяют своей подписью документ. Прошу прощения у специалистов, если сейчас не совсем точно объясню. Пара ключ и сертификат — похожа на пару замок и ключ. Каждый может подойти со своим ключом и попробовать открыть тот или иной замок. В случае электронного документооборота нужно гарантировать, что этот документ подписан именно тем-то (сравним с отпечатком пальца), а вот смотреть его будут другие, у кого нет ключа. Поэтому сертификат делается публичным — то есть может распространяться, но подписать им можно будет только, если у вас есть еще и ключ. А он, как правило, располагается на каком-то контейнере: рутокен, етокен, флешка, дискетка и т.д.
      • 0
        Сколько же можно!?

        Сертификат это просто файл специального формата где лежит ключ, закрытый или публичный.
        Возьмите любой сертификат и скоримите любому ASN.1 парсеру, узнаете много нового. Мне больше всех нравится: www.lapo.it/asn1js
        У меня закрытый ключ вообще лежит в xml файле, а публичный вшит в тело программы как две строки вида char *pk =«fa5638...».
        Те у меня ЭЦП совершается вообще без всяких сертификатов, и всё вполне работает. Даже без криптолиб всяких типа OpenSSL, я сам реализовал ECDSA, своя встраиваемая SHA2.

        Распространяется публичный ключ, то что он хранится в сертификате — это глубоко вторично.
        Есть ещё PGP, там ключи распространяются без всяких сертификатов, и без центров сертификации.

        А уж где физически хранится ключ это вообще дело третье, хоть на визитке распечатан.

        2 Disen:
        Сертификат это контейнер, что там внутри записано зависит от настроения того кто это туда пишет.
        Например, сертификаты для TLS не содержат никаких имён пользователей. А кроме открытых ключей ещё и закрытые пишут, обычно в отдельные сертификаты, но не обязательно.

        2 grossws:
        ЭЦП подразумевает что другая сторона имеет публичный ключ, а каким образом она его получила не важно.
        Ключ может быть вшит в софт или его могут принести на флешке/бумажке, или это может быть PGP с сетями доверия.
        Я для личных нужд делаю «самоподписной» и ручками ставлю где надо, и никаких CA.

        То что ЭЦП ассоциируется исключительно с центрами сертификации, крипто про, злым + кривым + непонятным софтом, чёрной магией в доменах и тп это исключительно ваша особенность восприятия термина ЭЦП.
        ЭЦП (DSA) гораздо шире и применяется гораздо чаще, чем при работе с домене, госухой и всякими комерсами.
        Это и SSL/TLS и всякие VPN и куча других не очевидных мест.

        Лично мне очень не нравится текущая ситуация, когда за ПО для эцп нужно платить, за сертификаты платить и тп.
        Это всё так же нелепо как покупать браузер для интернет или платить за почтовый ящик.
        • 0
          Сертификат это просто файл специального формата где лежит ключ, закрытый или публичный.
          1. Приведите примеры, когда сертификат содержит закрытый ключ. Когда он лежит в каком-нибудь контейнере рядом с закрытым ключом (типа PKCS12), то это вполне понятно.
          2. Сертификат кроме, собственно, публичного ключа содержит другую важную информацию:
          — кому принадлежит (DN) в том или ином виде (X.500-like DN в X.509, uid в PGP),
          — тип ключа, алгоритм подписи
          — подпись ключевого материала (CA в случае X.509, другие пользователи в PGP WoT),
          — ограничения (сроки действия, использования и т. п.),
          — прочее говно (в x509 всякие crl, ocsp-responder, issuer, хэши ключевой информации и прочее).

          Если говорить про ЭЦП с точки зрения технологии, то для неё достаточно ключевой пары. Если говорить про ЭЦП с юридической точки зрения, то она требует наличия авторизованного CA, который обязан проверить полноту и достоверность сведений, идентифицировать желающего получить ЭЦП. В рамках этого поста под ЭЦП понимают, скорее, второй вариант. А он невозможен без авторизованного CA (также, как и паспорт, можно получить только через авторизованные организации).

          Например, сертификаты для TLS не содержат никаких имён пользователей.
          Это не так. Клиентский TLS может запросто содержать, например, /CN=Ivan Ivanov/emailAddress=ii@example.com/.

          ЭЦП (DSA) гораздо шире и применяется гораздо чаще, чем при работе с домене, госухой и всякими комерсами.
          Это и SSL/TLS и всякие VPN и куча других не очевидных мест.
          DSA — Digital Signature Algorithm — это только один, ныне редкоиспользуемый, алгоритм подписи. Давно вы видели TLS с DSS в ciphersuite? Куда чаще используется RSA, ECDSA и EdDSA.

          за сертификаты платить
          Есть разные варианты: бесплатный startssl, wosign; просто говно от comodo за $5 на обычный или $60 на wildcard. Или ждите введения DANE (но за домен всё равно платить придётся), бесплатных сертификатов от Mozilla и т. п.
    • +1
      Сертификат это просто контейнер для хранения ххх бит случайных данных, которые и являются секретным ключём.

      Вы допустили опечатку. Всё-таки сертификат — это контейнер с информацией о пользователе и его открытый ключ.
      • 0
        И, в случае PKI, подписью CA, т. к. без PKI сертификат бесполезен в качестве средства ЭЦП.
  • 0
    1. Когда генерируешь самодписной средствами OpenSSL.
    На тех же вебсерверах они лежат, для работы TLS.

    2. Да, я в курсе что туда можно много чего понапихать.

    С юридической точки зрения CA не обязателен.
    Вполне можно заключить на бумаге договор между двумя лицами, где будут прописаны их публичные ключи и то что подписанные ЭЦП документы по соответствующим закрытым ключам считаются действительными.
    Потому не нужно натягивать СА как обязательный элемент для ЭЦП.

    en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm
    «Elliptic Curve Digital Signature Algorithm (ECDSA) offers a variant of the Digital Signature Algorithm (DSA)»
    У них там понятия ЭЦП, есть DSA, насколько я понимаю. Про то это ныне устаревший алгоритм я знаю.

    Я не плачу за собственную подпись, и не хочу платить за собственную цифровую подпись, потому что считаю это в корне не правильным.
    Так же меня не устраивают все эти CA, которые кому то принадлежат, я их не знаю и доверия у меня к ним нет.
    Если бы был вариант мульти СА, когда мою цп заверяют одновременно разные СА, например Россия, США, Китай и ещё кто нибудь, то это хотя бы от части могло что то гарантировать.
    • –1
      Если бы был вариант мульти СА
      В этом плане мне нравится PGP.
      Кстати, существуют ли «центры сертификации» для него (неё?), подписывающие сертификаты пользователей автоматически или даже с ручной проверкой?
    • 0
      Догадываюсь, что вы пытались ответить мне, но перенести в соответствующую ветку не сможете.

      1. Когда генерируешь самодписной средствами OpenSSL.
      На тех же вебсерверах они лежат, для работы TLS.
      Приведите пример создания сертификата, когда в теле сертификата оказывается приватный ключ. Результат с двумя сконкатенированными PEM-блоками в base64 не считаются.

      С юридической точки зрения CA не обязателен.
      Для части документов это так. Часть документов (например, счета-фактуры) следует подписывать квалифицированной подписью, чтобы они были приняты к рассмотрению при расчёте налогов. А часть документов можно спокойно подписывать простой электронной подписью, если договор или доп. соглашение устанавливает такую договорённость между коммерческими организациями. Судя по описанной арбитражной практике такая подпись вполне работает как аналог собственноручной + печати. Насчёт взаимодействия физик-физик или юрик-физик — не знаю. Стоит также добавить, что некоторые договора могут заключаться только на бумаге (по ГК РФ).

      Аналогично, взаимодействие с некоторыми площадками (всякие ФНС, ФСС, госзакупки), порталами госуслуг и т. п. может требовать квалифицированной подписи, согласно 63-фз, что потребует получить сертификат у аккредитованного УЦ.

      Если бы был вариант мульти СА, когда мою цп заверяют одновременно разные СА, например Россия, США, Китай и ещё кто нибудь, то это хотя бы от части могло что то гарантировать.
      Хотите WoT — используйте PGP/GnuPG, там люди удостоверяют, что вы — это вы (и что они видели, как минимум какой-нибудь id, удостоверяющий личность). Была ещё инициатива cacert.org, там тоже через сеть доверия удостоверяли личность.

      en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm
      «Elliptic Curve Digital Signature Algorithm (ECDSA) offers a variant of the Digital Signature Algorithm (DSA)»
      У них там понятия ЭЦП, есть DSA, насколько я понимаю. Про то это ныне устаревший алгоритм я знаю.
      Непонятно, что вы хотели этим сказать. ЭЦП (digital signature) != DSA, т. к. DSA — частный алгоритм ЭЦП. ECDSA — то же самое, но на группе точек эллиптической кривой, а не в конечном поле целых чисел. Если посмотреть на страницу, посвящённую DSA, то там сказано:
      The Digital Signature Algorithm (DSA) is a Federal Information Processing Standard for digital signatures.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.