Серийный номер сертификата ключа подписи как посмотреть продление ЭЦП

Pay-to-public-key-hash сценарии

Большинство транзакций, наполняющих сегодня сеть Биткоин, используют один и тот же сценарий проверки валидности — Pay-to-Public-Key-Hash (P2PKH, платеж на хеш открытого ключа), проецирующий на криптовалютную платформу простейшую операцию перевода денежных средств от одного лица другому, но только в обезличенной форме.

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


Вернемся к рассмотренному ранее примеру с Мариной, оплатившей биткоинами чашку кофе, выпитую в кофейне Сергея. Выход соответствующей транзакции будет заблокирован скриптом scriptPubKey следующей конструкции:

«Public-Key-Hash Сергея» представляет собой биткоин-адрес кошелька владельца кофейни в шестнадцатеричном формате (т.е., без перевода в кодировку Base58Check с характерной для этого случая «1» вначале). Это вполне естественно, если вспомнить, что формат Base58Check придуман для лучшего восприятия больших чисел людьми. А компьютеры легко разберутся и с шестнадцатеричным представлением данных.

Когда Сергею понадобятся эти средства, он легко сможет снять с них обременение с помощью следующего разблокирующего скрипта (scriptSig), входящего в состав новой транзакции (в качестве одного из ее входов):

Здесь под термом Signature понимается электронная подпись владельца криптопары.


Если объединить оба скрипта в один сценарий, мы получим уже отчасти знакомый нам программный код на языке Script:

После выполнения этого комбинированного сценария, мы получим на вершине стека единственное значение «ИСТИНА» тогда и только тогда, когда разблокирующий скрипт подойдет условиям, закодированным в блокирующем скрипте. Воспользоваться средствами может только обладатель закрытого ключа Сергея, представив для снятия обременения свою электронную подпись. В штатной ситуации это и есть сам Сергей.

Ход выполнения сценария в случае P2PKH-транзакции проиллюстрирован рисунком 3.5 (в целях улучшения восприятия у операторов языка Script на рисунке опущены префиксы OP_). Причину разделения процесса на две части Вы уже знаете. Скрипты объединенного сценария выполняются последовательно, а результат первого передается во второй посредством стека.

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

В самом начале второй части комбинированного сценария — скрипта обременения scriptPubKey выполняется дублирование указателя стека, т.е., самого верхнего значения — открытого ключа. Инструкция OP_HASH160 на самом деле вычисляет двойной хеш, применяя последовательно хеш-функции SHA-256 и RIPEMD-160 к указателю стека (значению на вершине), а полученный результат вновь добавляется в стек. Т.е., на вершине стека окажется величина, равная RIPEMD-160(SHA-256(<отрытый ключ>)).

Мы с Вами помним, что это формула вычисления биткоин-адреса. Аналогичная по смыслу величина у нас вшита в самом скрипте обременения – биткоин-адрес, на который собственно и были в свое время отправлены средства. Это следующий операнд скрипта, появление которого в нем означает, что биткоин-адрес получателя платежа размещается на вершине стека.

Осталось их сравнить. Что и делает инструкция OP_EQUALVERIFY. С ее помощью из стека выбираются два верхних значения (биткоин-адрес действительного получателя средств и биткоин-адрес претендента на эти средства) и осуществляется их сравнение.

Результат сравнения добавляется к стеку. На самом деле команда OP_EQUALVERIFY немного мощнее, чем простой оператор сравнения, который также в синтаксисе языка Script присутствует — OP_EQUAL.

Инструкция OP_EQUALVERIFY подразумевает также в конце исполнения вызов команды OP_VERIFY, отмечающую транзакцию как недействительную, если на вершине стека оказывается значение не равное TRUE.

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

А эту задачу легко можно решить достаточно традиционным способом. Имея пару электронная подпись и открытый ключ, мы всегда можем проверить подходят ли они друг к другу. Именно эту функцию и выполняет последняя инструкция сценария OP_CHECKSIG.

Если проверка пройдет успешно, на вершине опустевшего к моменту завершения сценария стека окажется значение 1 (TRUE). В противном случае указатель стека будет возвращать значение 0 – транзакция недействительная.

Хотя относительно реализации последнего шага и был употреблен эпитет «традиционно», это утверждение не является справедливым. Традиционной можно назвать процедуру использования открытого ключа для проверки электронной подписи. А вот идея проверки принадлежности публичного ключа на основе электронной подписи является весьма оригинальной. Впрочем, так можно охарактеризовать практически любой компонент платформы Биткоин.

Осталось рассмотреть всего один вопрос. Подпись всегда ставится под документом. Электронная подпись не исключение. На основании какого электронного документа создается электронная подпись в скрипте scriptSig? Электронная подпись генерируется на основе дайджеста (результата хеширования) некоторых полей данной транзакции.

Pay-to-script-hash (p2sh) сценарии

Модель Pay-to-script-hash (P2SH) была введена в 2021 году в качестве нового типа транзакций, существенно расширяющего спектр поддерживаемых платформой финансовых схем. Появилась возможность использовать сложные сценарий транзакций. Эту модель часто путают с мульти-подписью, однако сфера применения P2SH-скриптов гораздо шире.

Если отталкиваться только от скриптов обременения, так вариабельность условий обременения вообще становится практически безграничной. Достичь это позволило весьма элегантное решение. Средства отправляются на адрес скрипта. При этом что из себя представляет скрипт заранее никак не оговаривается – он может быть любым.

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

Именно ему придется представить скрипт в качестве доказательства своего права на заблокированные в выходе P2SH-транзакции средства. Согласитесь, логика проверки по сравнению с предыдущими моделями иная. Очень мощное с точки зрения масштабируемости функционала платформы решение.

Итак, в P2SH-транзакции биткоины традиционно блокируются в скрипте, но сам скрипт не добавляется в выход транзакции (в поле scriptPubKey). Вместо этого, скрипт обременения хешируется. Полученный дайджест никак не может быть использован для восстановления исходного скрипта.

Однако, имея на руках исходный скрипт, можно легко получить точно такой же дайджест путем повторного хеширования скрипта. Хеш сценария — это и есть та информация, которая включается в выход транзакции (в поле scriptPubKey). Для того, чтобы такой выход в следующей транзакции, недостаточно просто выполнить условия, определенные в сценарии, так как ноды сети Биткоин видят только дайджест хеша скрипта и поэтому о самом скрипте им ничего не известно.

Следовательно, ноды не могут удостовериться в том, что условия, определенные в комбинированном сценарии выполнены. То есть, они не могут подтвердить транзакцию. Поэтому, чтобы разблокировать и растратить средства, транзакция должна включать в себя, вместе с условиями, определенными в скрипте, и сам скрипт.

В этом случае ноды сети Биткоин, вычислив хеш приложенного сценарий, могут сравнить его с хешем, размещенным в выходе предыдущей транзакции. В случае совпадения нодам остается только проверить правильность выполнения условий, определенных в сценарии, после чего транзакция признается действительной. Рисунок 3.6 иллюстрирует изложенный процесс.


Таким образом, P2SH-модель по сути реализует следующее финансовое предписание «заплатить при предъявлении скрипта, соответствующего данному хешу».

Чем же модель P2SH отличается от мульти-подписи? Рассмотрим простой пример схемы с корпоративным управлением доступа к средствам, обеспечивающим высокую степень безопасности. Пусть какая-то компания использует механизм мульти-подписи для всех платежей, поступивших от клиентов.

Комбинированный сценарий траты средств в этом случае выглядит следующим образом:

Недостаток такого сценария очевиден – он слишком длинный. Мы помним, что в распределенных системах следует экономить на каждом байте блокчейна. К тому же вторая часть сценария (скрипт scriptPubKey) должен предварительно быть доведен до каждого клиента, чтобы они смогли его использовать в своих платежных транзакциях.

Организационно это не самое удобное решение. Клиенты должны пользоваться специальными кошельками, быть в курсе процедуры создания мульти-подписных транзакций и платить повышенную комиссию майнерам за обработку огромных транзакций (из-за большой длины открытых ключей, которых в блокирующем скрипте стало намного больше, чем в традиционном P2PKH-выходе).

Даже не будем вспоминать о дополнительной нагрузке на оперативную память каждой полной ноды, в которой должны храниться все подобные нерастраченные выходы (в пуле UTXO). Все перечисленные проблемы серьезно осложняют применение сложных скриптов обременения на практике.

Читайте также:  Как установить сертификат ЭЦП на компьютер?

Pay-to-script-hash модель как раз и была разработана для решения указанных проблем.

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

Биктоин-адрес формата P2SH всегда начинается с 3, а не 1, как в P2PKH-адресах. Это связано с тем, что P2SH-адреса перед кодированием по стандарту base58check дополняются префиксом байта версии, равным 0x05 (в шестнадцатеричном формате), а не 0x00 (в шестнадцатеричном формате), характерным для P2PKH-адресов.

А теперь вместо мнемонических обозначений в блокирующий скрипт подставим реальные открытые ключи (520-разрядные двоичные числа, начинающиеся с 0х04):

Пугает, правда? Зато в P2SH-сценарии весь этот ужас представляется 20-ти байтным дайджестом — результатом хеширования блокирующего скрипта с помощью последовательного применения алгоритмов SHA-256 и RIPEMD-160, т.е., RIPEMD-160(SHA-256(<код блокирующего скрипта>)). Для нашего конкретного случая это всего-то:


Выход P2SH-транзакция будет обременен с помощью следующего блокирующего скрипта:

Это все, что нужно знать клиенту для проведения платежа в адрес рассматриваемой в примере компании. Размер такой транзакции не будет превышать размеров обычных транзакций (по крайней мере по причине раздутого скрипта scriptPubKey) и проведение платежа не потребует от клиента затрат на повышенную комиссию майнерам.

Как же можно снять обременение с такого нерастраченного выхода? Ведь биткоин-адреса получателя средств, в привычном для нас с Вами понимании, в P2SH-сценарии больше нет. Необходимо создать вход, в котором представлен оригинальный код погашающего скрипта (того самого, хеш которого использовался при обременении средств) и подписи двух или более владельцев компании — в качестве удовлетворения условий обременения выхода — погашающего скрипта. Например:


Комбинированный сценарий проверки притязаний на заблокированные средства, выраженных приведенным выше входом транзакции, выполняется в два этапа. Во-первых, погашающий сценарий проверяется разблокирующим скриптом на предмет совпадения хеша:

Если проверочный сценарий заканчивается успешно (в стеке окажется единственное значение ИСТИНА), переходим ко второму этапу, на котором мы фактически имеем дело с обычной процедурой проверки комбинированного сценария, включающего модифицированный разблокирующий скрипт (<Условия снятия обременения> <Погашающий скрипт>):

Далее все происходит точно также как и в случае проверки обычной транзакции.

Входы и выходы транзакции

Цель: Сформировать комплекс знаний о строении входов и выходов транзакции, составе, функциях и взаимосвязи их структурных компонентов.

Безусловно, это самые интересные и важные части транзакции. Концептуальным элементом схемы являются неизрасходованные выходы транзакций (Unspent TransactionOutput) или UTXO.

Биткоин был первой валютой, реализующей модель UTXO для отслеживания состояния реестра. Каждая очередная транзакция расходует выходы предыдущих и создает новые выходы, которые в свою очередь будут израсходованы последующими транзакциями.

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

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

Отметим, что модель UTXO подвергается определенной критике. Оппоненты утверждают, что технические решения, основанные на подобной схеме, подходят только для тех предметных областей, где каждый выход имеет строго одного владельца.

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


К счастью, в этом разделе книги мы рассматриваем именно криптовалюту. Даже самые ярые критики UTXO признают, что для данной цели модель UTXO подходит наилучшим образом.

Итак, платформа Биткоин отслеживает все доступные (неизрасходованные) выходы UTXO (на февраль 2021 года общая масса выпущенной криптовалюты превысила 16 840 000 BTC). Каждый раз, когда пользователь так или иначе получает биткоин, эта сумма учитывается в платформе как нерастраченный выход.

Таким образом, средства конкретного пользователя могут быть раскиданы по пулу UTXO среди тысяч транзакций и сотен блоков. Именно поэтому платформа исключает такое понятие как баланс биткоин-адреса или счета и оперирует только отдельными нерастраченными выходами, привязанными к конкретному владельцу.

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

Неизрасходованный выход транзакции может блокировать любую произвольную сумму в биткоинах (или сатоши). При этом он является неделимым (не станете же Вы отрывать кусочки от пятитысячной купюры для оплаты покупки в 500 рублей). Аналогия тут совершенно полная.

Это означает, что для осуществления сделки требующей купюры меньшего номинала, чем имеющийся в Вашем распоряжении неизрасходованный выход, Вам все равно придется потратить его целиком. На самом деле все не так печально. Сдачу самому себе никто не отменял. Т.е., транзакция кроме одного выхода, отправляющего требуемую сумму по адресу получателя платежа, будет содержать еще один выход – сдачу самому себе (аналогичным образом, если средств в одном нерастраченном выходе недостаточно, следует аккумулировать несколько UTXO, т.е., транзакция может включать несколько входов). Ну и о вознаграждении майнерам не стоит забывать. Все ровно так как показано на рисунке 4.

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

Почему модель UTXO называют симметричной? Нерастраченные выходы в блокчейне, которые транзакция потребляет являются ее входами. Одновременно с этим создаются новые нерастраченные выходы, которые становятся выходами данной транзакции. Фраза конечно звучит не очень благозвучно, но по сути здесь все верно.

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

А теперь попробуйте ответить на вопрос: что является первичным вход или выход транзакции?

Есть только одно исключение из сформулированного правила в модели UTXO. Речь идет о так называемых coinbase-транзакциях, являющихся источником эмиссии криптовалюты Биткоин. Эти токены отправляются майнеру, которому удалось сформировать очередной валидный блок, включенный в блокчейн.

Первой транзакцией любого блока является такая coinbase-транзакция, фиксирующая факт перевода майнеру, сгенерировавшему этот блок, гонорара за его труды. Разумеется, майнер сам эту транзакцию и формирует в процессе создания блока.

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

Признаться, в блокчейне Биткоина есть еще одна особая, единственная транзакция, входящая в его генезис-блок. Первые 50 BTC были отправлены Сатоши Накамото по адресу 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa.

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

Как мы уже знаем, передача биткоинов — это создание неизрасходованного выхода транзакции (UTXO), зарегистрированного на получателя платежа. Каждая полная нода в сети Биткоин отслеживает множество (пул) нерастраченных выходов (UTXO).

Инструкция по генерации ключа электронной подписи

Оглавление

1.  Перед началом генерации.

2.  Установка приложения.

3.  Предоставление доступа.

4.  Установка КриптоПРО CSP.

5.  Установка драйвера для токена.

6.  Формирование запроса на сертификат.

7.  Запись сертификата на ключевой носитель.

ОСНОВНЫЕ ПОНЯТИЯ

КСКПЭП  квалифицированный сертификат ключа проверки электронной подписи.
КЭП – квалифицированная электронная подпись.

Криптопровайдер – средство защиты криптографической защиты информации. Программа с помощью которой генерируется закрытая часть электронной подписи и которая позволяет производить работу с электронной подписью. Данная галочка проставляется автоматически.

Экспортируемый ключ – возможность копирования электронной подписи на другой носитель. При отсутствии галочки копирование электронной подписи будет невозможно.

ЛКМ – левая кнопка мыши.

ПКМ – правая кнопка мыши.

CRM-AGENT – приложение, разработанное специалистами УЦ для упрощения процедуры генерации ключевой пары, создания запроса и записи сертификата.

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

Откройте ссылку для генерации из письма в одном из рекомендуемых браузеров: Google ChromeMozilla FirefoxYandex.Браузер. Если Вы уже находитесь в одном из вышеперечисленных браузеров, кликните по ссылке ЛКМ или ПКМ > «Открыть ссылку в новой вкладке». Страница генерации (Рис.1) откроется в новом окне.

При открытии ссылки, появится первоначальное предупреждение. Ознакомьтесь с ним, если для хранения КЭП вы используете носитель Jacarta LT. Подробнее о носителях в Таблице 1 ниже. Если используете иной носитель, то нажмите кнопку «Закрыть».

Рис.1 – Страница генерации

1

Нажмите на ссылку «Скачать приложение» для начала загрузки. Если ничего не произошло после нажатия, кликните по ссылке ПКМ > «Открыть ссылку в новой вкладке». После скачивания приложения запустите установку.

Рекомендуется отключить антивирусное ПО перед загрузкой программы!

В процессе установки приложения «crmagent» появится сообщение с запросом доступа (Рис.2).

Рис.2 – Запрос доступа

2

Нажмите кнопку «Да».

После окончания установки приложения вернитесь на страницу с генерацией. Появится сообщение о «Предоставлении доступа» (Рис.3).

Рис.3 – Доступ к хранилищу сертификатов

54

Нажмите «Продолжить» и, в появившемся окне, «Предоставить доступ» (Рис.4).

Рис.4 – Доступ к хранилищу сертификатов 2

5

Если не появилась кнопка «Продолжить»

Если после установки приложения «crmagent», ссылка на скачивание приложения не исчезла, причиной может быть блокировка подключения вашей системой безопасности.

Для устранения ситуации необходимо:

Отключить антивирус, установленный на вашем компьютере;

Открыть новую вкладку в браузере;

Ввести в адресную строку браузера адрес без пробелов — 127.0.0.1:90 – и перейти (нажать Enter на клавиатуре);

При появлении сообщения браузера «Ваше подключение не защищено», добавьте страницу в исключения браузера. Например, Chrome«Дополнительные» — «Все равно перейти на сайт». Для остальных браузеров воспользуйтесь соответствующей инструкцией разработчика.

После появления сообщения об ошибке, вернитесь на страницу с генерацией и повторите Пункт 2 данной инструкции.

В случае, если у вас отсутствуют предустановленные криптопровайдеры, после этапа предоставления доступа появятся ссылки для скачивания КриптоПРО (Рис.5).

Рис.5 – Загрузка КриптоПРО

6

Это важно: приложение «crmagent» обнаруживает любые криптопровайдеры на компьютере, и, если у Вас установлена отличная от КриптоПРО CSP программа (например, VipNET CSP), свяжитесь со специалистами технической поддержки УЦ для консультации.

Нажмите на ссылку «КриптоПРО 4.0» на странице генерации или на аналогичную ссылку ниже для загрузки файла установки КриптоПРО на компьютер.

КриптоПро CSP 4.0 – версия для ОС Win 7 / 8 / 10

После окончания загрузки откройте zip-архив с помощью соответствующей программы-архиватора (например, WinRAR). Внутри будет сам файл установки КриптоПРО. Запустите его и установите с параметрами по умолчанию. В процессе установки у Вас может появиться следующее окно:

Рис.5 – Установка КриптоПРО

7

Пропустите окно, нажав «Далее». Установка КриптоПРО завершена.

Подписи можно хранить в реестре компьютера, на обычных флеш-накопителях и на специальных usb-токенах. Список токенов, пин-коды и ссылки на ПО представлены в таблице ниже (Таблица 1).

Таблица 1 – Драйверы для защищенных носителей

Визуально определите ваш носитель.

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

Теперь Вы можете приступать к формированию запроса на сертификат. На экране у вас появится сообщение об этом (Рис.6). Нажмите кнопку «Продолжить» для начала формирования запроса.

Рис.6 – Начало формирования запроса

8

Откроется дополнительное окно с предложением выбрать, куда записать КЭП (Рис.7). Есть возможность выбрать в качестве носителя:

Реестр – хранилище «внутри» компьютера;

Диск {X} – обычный флэш-накопитель;

ARDS JaCarta Activ Co Rutoken 0 и т.п. – защищенный токен.

Рис.7 – Выбор носителя

15

Передвигая ползунок, выберите носитель для хранения КЭП и нажмите «ОК». Если был выбран «Реестр», то система в дальнейшем предупредит о возможном риске. Продолжите, если Вы осознанно выбрали реестр в качестве носителя для КЭП. Если случайно, то повторите формирование запроса повторно.

Это важно: в качестве хранилища КЭП для электронных торговых площадок можно использовать только защищенный носитель — токен. Если нет токена или драйвер установлен, но сам токен не работает, то свяжитесь со специалистами технической поддержки УЦ для консультации.

После выбора носителя откроется окно генерации «Датчик случайных чисел» (Рис.8). Для заполнения шкалы необходимо быстро и часто нажимать на цифровые клавиши на клавиатуре или передвигать мышь в пределах окна. Может потребоваться повторить процедуру несколько раз.

Рис.8 – Датчик случайных чисел

16

По окончанию процесса откроется окно с предложением задать пароль (Рис.8) для контейнера, если был выбран обычный флеш-накопитель или реестр. Рекомендуется не задавать пароль и пропускать данный пункт нажатием кнопки «ОК» без ввода и подтверждения пароля.

Рис.8 – Ввод пароля

17

Если вы выбрали в качестве носителя токен, тогда необходимо ввести pin-код. Стандартные pin-коды носителей указаны в Таблице 1 выше. Выбрать токен для хранения и пройти датчик случайных чисел может потребоваться дважды, так как на данный момент выпускается две аналогичные КЭП: по старому ГОСТ 2001 и по новому ГОСТ 2021.

Это важно: количество попыток ввода pin ограничено и, если pin введен неверно несколько раз, то носитель может быть заблокирован. В таком случае, свяжитесь со специалистами технической поддержки УЦ для консультации.

При успешном завершении генерации появится следующее (Рис.9) сообщение:

Рис.9 – Завершение генерации

18

Завершена процедура по созданию закрытой части ключа электронной подписи и отправка запроса на сертификат. Если в качестве носителя у Вас флеш-накопитель (флешка), то доступ к файлам электронной подписи открыт пользователям и антивирусному ПО. В таком случае есть риск утери закрытой части, после чего потребуется перевыпуск. Чтобы обезопасить себя от нежелательных последствий хранения КЭП на флеш-накопителе, сохраните копию папки с флеш-накопителя на своём компьютере и заархивируйте скопированный образец.

Это важно: категорически не рекомендуется осуществлять действия с этими файлами: перенос, изменение наименования, редактирование. При утере электронной подписи, требуется платный перевыпуск КЭП. Создавать копию созданной в процессе генерации папки – безопасно.

Спустя 5 минут после завершения этапа генерации, обновите страницу генерации, нажав клавишу F5 или соответствующую кнопку в браузере. Если запрос на выпуск сертификата уже одобрили, появится страница для записи сертификата в контейнер ключа (Рис.10). По ссылке из пункта 1 «Скачайте бланк для подписи» на этой странице скачайте бланк сертификата, распечатайте его. Владелец сертификата, на чье имя была выпущена КЭП, должен подписать бланк.

Рис.10 – Сертификат одобрен

19

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

Рис.11 – Бланк загружен

20

Кликните на ссылку «Записать сертификат на ключевой носитель», откроется дополнительное окно (Рис.12).

Рис.12 – Запись сертификата

21

Нажмите кнопку «Продолжить» — в появившемся окошке «Предоставить доступ». Для завершения записи кликните кнопку «Начать». Появится сообщение об успехе операции (Рис. 13).

Рис.12 – Завершение записи сертфиката

22

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

Читайте также:  КриптоПро | КриптоПро PDF - Часто задаваемые вопросы

Скачать инструкцию

Обновление segregated witness

Цель: Сформировать представление о сути и задачах, выполняемых обновлением Segregated Witness (SegWit).

В 2021 году был активирован протокол Segregated Witness (SegWit) – самый крупный на сегодняшний день софтварный апгрейд в сети Биткоин, целью которого было дальнейшее масштабирование, снижение транзакционных комиссий и увеличение лимита блоков.

Для понимания проблемы, которую решает SegWit, необходимо внимательнее рассмотреть, как устроены биткоин-транзакции. Состоят они из двух главных частей: основных данных о транзакции, к которым, например, относится информация о том, какие именно перемещаются монеты и в каком направлении, и, так называемого, «свидетеля» (witness).

Речь идет о части кода (которую называют scriptSig, witness или же разблокирующий скрипт) с данными электронной подписи, служащей доказательством того, что владелец монет действительно хочет их потратить.

Именно в этих данных заключена небольшая проблема, получившая название пластичности транзакции. Ее суть состоит в том, что подписи могут быть изменены даже после их создания и при этом они остаются действительными. Это означает, что те, кто транслируют транзакцию, или майнеры, которые включают ее в блок, могут изменить внешний вид этой транзакции, или, если говорить более предметно, ее идентификатор.

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

Разберемся в этих проблемах более основательно. Напомним, что идентификатор транзакции (он же хеш транзакции — txid) – это 64-разрядное шестнадцатеричное число (256 бит), которое представляет собой идентификационный номер, уникальный для каждой транзакции в блокчейне Биткоин. Такие же идентификаторы используются и в других платформах.

Читайте также:  Соглашение об электронном документообороте с ПФР: бланк, образец заявления, как оформить договор на подключение ЭДО

Например, идентификатор транзакции в сети Биткоин выглядит так:

Идентификатор транзакции в платформе Ethereum выглядит практически также:

Дискуссии о решении проблемы пластичности транзакций посредством «отделения» данных о подписи от остальных данных транзакции начались еще в январе 2021 года. Среди прочих в них принимали участие разработчики Bitcoin Core Расселл О’Коннор, Мэтт Коралло, Люк Дэш-младший и Грегори Максвелл, а также модератор форума Bitcointalk Theymos. Однако подходящего решения тогда так найдено и не было.

Segregated Witness (сокращенно SegWit) — обновление платформы Биткоин, призванное решить две основных проблемы данной криптовалюты. Речь идет об обеспечении пластичности транзакций блокчейна Биткоин, а также об увеличении пропускной способности системы.

Аналогичное по сути техническое решение реализовано и для целого ряда альткоинов, таких как Litecoin, DigiByte, Groestlcoin и Vertcoin. Обновление позволяет уменьшить размер транзакций, делая блоки более вместительными, а также снимает проблему пластичности («изменчивости» transaction malleability), что очень важно для технологий наподобие платежных каналов или лайтнинга, полагающихся на строение транзакции сети Биткоин.

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

https://www.youtube.com/watch?v=3LhSrA0wBrU

Для достижения цели данные, инкапсулирующие электронные подписи и блокирующие скрипты выделены в обособленную структуру под названием «отдельный свидетель» (англ. segregated witness). Поскольку размеры каждой транзакции стали существенно меньше, основные блоки способны вместить большее число транзакций.

Серийный номер сертификата ключа подписи как посмотреть продление ЭЦП

Форк (от англ. Fork — вилка) — процесс, в результета которого создается альтернативная успешная версия блокчейна. Подобное может произойти умышленно — в случае сосредоточения под контролем группы майнеров вычислительных мощностей, достаточных для влияния на консенсус сети (атака 51%), случайно (когда нескольким майнерам одновременно удается записать новые блоки, что приведет к ветвлению блокчейна, или в результате ошибки системы), а также целенаправленно при решении команды разработчиков расширить функционал системы (или исправить ранее допущенные ошибки) в новых версиях клиентского программного обеспечения.

Форк признается успешным, если его ветвь становится цепочкой блоков с максимальной суммарной сложностью доказательств консенсуса. В этом случае альтернативная ветка блокчейна отвергается и в дальнейшем в системе не развивается.

Также форком называют изменения протокола криптовалюты, приводящие к созданию двух различных версий блокчейна с единой историей.

Часто форком называют новую криптовалюту, основанную на протоколе действующей платежной платформы. Например, большинство известных криптовалют являются форками сети Биткоин.

Язык сценариев транзакций

Цель: Сформировать представление о языке сценариев транзакций Script в необходимом объеме.

Проверка валидности транзакции в сети Биткоин осуществляется на основе выполнения скрипта, записанного на специальном языке сценариев, называемым Script. Это Форт (Forth) – подобный стековый язык программирования с обратной польской нотацией, позволяющей избежать присутствия скобок и приоритетов в выражениях, что чрезвычайно удобно для вычисления формул в ЭВМ на основе стеков.

Важная особенность таких языков — использование стека для передачи параметров между термами, что позволяет очень гибко и просто реализовывать достаточно сложные конструкции. Отличительная особенность обратной польской нотации заключается в том, что аргументы располагаются перед знаком операции. Стек — это коллекция, элементы которой доступны согласно принципа «последний вошел, первый вышел» («Last-In-First-Out», LIFO). Т.е., в любой момент времени мы будем иметь дело только с элементом, добавленным последним (лежащим на вершине стека).

Неполнота по Тьюрингу для языка Script в первую очередь означает отсутствие циклов и сложных инструментов управления ходом выполнения кода. Для сети Биткоин данное свойство означает ограничение сложности сценариев и предсказуемое время их выполнения.

Это решение принято, исходя из соображений безопасности системы. Ограничения языка Script гарантируют отсутствие бесконечных циклов или других форм так называемых «логических бомб», способных привести к атакам на отказ в обслуживании.

Почему в данном случае речь не идет о SMART-контрактах? Хотя некоторые принципы умных контрактов впервые были заложены именно в протоколе Биткоин, его платформа не может реализовать их в клиентском программном обеспечении по соображениям безопасности.

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

Он не является Тьюринг-полным, а сама платформа не имеет маркеров состояния, чтобы на их основе можно было проектировать приложения. К тому же пропускная способность сети Биткоин сильно ограничена, что также не позволяет создать систему многофункциональных контрактов.

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

Инструкции языка (всего их порядка 80) подразделяются на категории (управляющие, для работы со стеком, для работы со строковыми фрагментами, побитовые логические операции, арифметические, криптографические).

Например, оператор OP_ADD извлечет два операнда из стека, вычислит их сумму, и поместит полученный результат на вершину стека. А оператор OP_EQUAL извлекает два операнда из стека, сравнивает их и добавляет в стек результат сравнения (ИСТИНА (кодируется как цифра 1) – если операнды равны и ЛОЖЬ (кодируется как цифра 0) – в противном случае).

Рассмотрим пример скрипта для решения следующей задачи: проверить равна или нет числу 5 сумма двух чисел 2 и 3.

Сценарий решения этой простой задачи будет выглядеть следующим образом:


Логика выполнения сценария биткоин-клиентом демонстрируется на рисунке 3.2.

Транзакция признается действительной, если указатель стека принимает в итоге значениеTRUE (OP_TRUE), т.е. равен 1, или после выполнения скрипта, стек окажется пустым, или на его вершине окажется любое другое ненулевое значение.

Транзакция признается недействительными, если после выполнения скрипта на вершине стека окажется значениеFALSE (OP_FALSE), или выполнение сценария будет прервано оператором (например, OP_VERIFY, OP_RETURN), операторной скобкой (например, OP_ENDIF) и др.

https://www.youtube.com/watch?v=Ff2hcINdCzg

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


Возвращаясь к последнему примеру, мы может использовать в качестве блокирующего скрипта набор инструкций:

Разблокировать такой выход можно с помощью транзакции, вход которой содержит следующий скрипт разблокировки:

Программное обеспечение клиента объединяет блокирующий и разблокирующий сценарии, в результате чего получается уже знакомый нам скрипт:

Результат исполнения этого сценария равен OP_TRUE, следовательно, транзакцию следует считать действительной. Наверное, это не совсем надежная защита для заблокированных средств, поскольку выход с таким обременением может потратить любой, кто знает, что 2 3=5.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector