Хэш типа подписи, что это такое

Обновлено: 21.11.2024

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

Что такое цифровая подпись?

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

Зачем использовать цифровую подпись?

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

Как работают цифровые подписи?

Ознакомьтесь со следующими терминами, чтобы лучше понять, как работают цифровые подписи:

  • Хеш-функция. Хеш-функция (также называемая «хеш») представляет собой строку фиксированной длины из цифр и букв, сгенерированную с помощью математического алгоритма, и файл произвольного размера, такой как электронное письмо, документ, изображение или другой тип файла. данные. Эта сгенерированная строка уникальна для хешируемого файла и представляет собой одностороннюю функцию — вычисленный хэш нельзя обратить вспять, чтобы найти другие файлы, которые могут генерировать такое же значение хеш-функции. Некоторые из наиболее популярных алгоритмов хэширования, используемых сегодня, — это алгоритм безопасного хеширования-1 (SHA-1), семейство алгоритмов безопасного хеширования-2 (SHA-2 и SHA-256) и дайджест сообщения 5 (MD5).
  • Криптография с открытым ключом. Криптография с открытым ключом (также известная как асимметричное шифрование) — это криптографический метод, использующий систему пар ключей. Один ключ, называемый открытым ключом, шифрует данные. Другой ключ, называемый закрытым ключом, расшифровывает данные. Криптография с открытым ключом может использоваться несколькими способами для обеспечения конфиденциальности, целостности и подлинности. Криптография с открытым ключом может
    • Обеспечьте целостность, создав цифровую подпись сообщения с помощью закрытого ключа отправителя. Это делается путем хэширования сообщения и шифрования хэш-значения с помощью их закрытого ключа. При этом любые изменения в сообщении приведут к другому значению хеш-функции.
    • Обеспечьте конфиденциальность, зашифровав все сообщение с помощью открытого ключа получателя. Это означает, что только получатель, у которого есть соответствующий закрытый ключ, может прочитать сообщение.
    • Подтвердить личность пользователя с помощью открытого ключа и сверить его с центром сертификации.

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

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

    Почему следует использовать PKI или PGP с цифровыми подписями?

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

    Благодаря доверенной третьей стороне цифровые подписи можно использовать для идентификации и проверки личности и обеспечения целостности сообщения.

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

    Авторы

    Этот продукт предоставляется в соответствии с настоящим Уведомлением и настоящей Политикой конфиденциальности и использования.

    Криптографический хеш (иногда называемый «дайджестом») — это своего рода «подпись» для текста или файла данных. SHA-256 генерирует почти уникальную 256-битную (32-байтовую) подпись для текста. См. исходный код ниже.

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

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

    • "Challenge handshake authentication" (или "Challenge hash authentication") позволяет избежать передачи паролей в "чистом" виде — клиент может отправить хэш пароля через Интернет для проверки сервером без риска. исходного пароля перехватывается
    • защита от несанкционированного доступа — связать хэш сообщения с оригиналом, и получатель может повторно хешировать сообщение и сравнить его с предоставленным хэшем: если они совпадают, сообщение не изменяется; это также можно использовать для подтверждения отсутствия потери данных при передаче.
    • цифровые подписи более сложны, но, по сути, вы можете подписать хэш документа, зашифровав его своим закрытым ключом, создав цифровую подпись для документа. Затем любой другой пользователь может проверить, что вы аутентифицировали текст, расшифровав подпись с помощью вашего открытого ключа, чтобы снова получить исходный хэш, и сравнив его со своим хэшем текста.

    Обратите внимание, что хеш-функции не подходят для хранения зашифрованных паролей, поскольку они рассчитаны на быстрое вычисление и, следовательно, могут быть кандидатами для атак методом грубой силы. Функции получения ключа, такие как bcrypt или scrypt, рассчитаны на медленное вычисление и больше подходят для хранения паролей (в npm есть библиотеки bcrypt и scrypt, а в PHP есть реализация bcrypt с password_hash).

    SHA-256 — это одна из хеш-функций-преемников SHA-1 (вместе именуемых SHA-2) и одна из самых надежных доступных хэш-функций. SHA-256 кодировать ненамного сложнее, чем SHA-1, и он еще никоим образом не был скомпрометирован. 256-битный ключ делает его хорошей партнерской функцией для AES. Это определено в стандарте NIST (Национальный институт стандартов и технологий) «FIPS 180-4». NIST также предоставляет ряд тестовых векторов для проверки правильности реализации. В Википедии есть хорошее описание.

    В этой реализации JavaScript я попытался сделать сценарий как можно более ясным и кратким, а также как можно ближе к спецификации NIST, чтобы сделать работу сценария понятной.

    Этот скрипт ориентирован на хеширование текстовых сообщений, а не двоичных данных. Стандарт рассматривает хеширование только сообщений байтового (или битового) потока. Текст, который содержит (многобайтовые) символы, не соответствующие стандарту ISO 8859-1 (т. е. символы с диакритическими знаками, не входящие в набор символов Latin-1 или неевропейский набор символов — что-либо с кодовой точкой Unicode выше U+FF), не может быть закодирован 4-в- слово, поэтому сценарий по умолчанию кодирует текст как UTF-8 перед его хешированием.

    Примечания по реализации этапа предварительной обработки:

    • FIPS 180-4 указывает, что к сообщению добавляется бит «1», а затем оно дополняется целым числом 512-битных блоков, включая длину сообщения (в битах) в последних 64 битах последнего блока.
    • Поскольку у нас есть поток байтов, а не поток битов, добавление байта «10000000» (0x80) добавляет необходимый бит «1».
    • Чтобы преобразовать сообщение в 512-битные блоки, я вычисляю необходимое количество блоков, N, затем для каждого из них я создаю 16-целочисленный (т.е. 512-битный) массив. Для каждого из этих целых чисел я беру четыре байта из сообщения (используя charCodeAt) и сдвигаю их влево на соответствующую величину, чтобы упаковать их в 32-битное целое число.
    • Метод charCodeAt() возвращает NaN для выхода за границы, но оператор «|» преобразует его в ноль, поэтому заполнение нулями выполняется неявно при преобразовании в блоки.
    • Затем длина сообщения (в битах) должна быть добавлена ​​к последним 64 битам, то есть к последним двум целым числам в последнем блоке. В принципе, это можно сделать с помощью
      M[N-1][14] = ((msg.length-1)*8) >>> 32;
      M[N-1][15] = ((msg.length-1)*8) & 0xffffffff;
      Однако битовые операции JavaScript преобразуют свои аргументы в 32-битные, поэтому n >>> 32 даст 0. Поэтому вместо этого я использую арифметические операторы: для старшего значащего 32-битного числа я делю (исходное ) length на 2^32 и используйте floor() для преобразования результата в целое число.

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

    При использовании Chrome на ПК с процессором Core i5 от низкого до среднего, в тестах синхронизации этот скрипт будет хэшировать короткое сообщение примерно за 0,03–0,06 мс; более длинные сообщения будут хешироваться со скоростью около 2–3 МБ/с.

    Если вас интересует более простой SHA-1, у меня есть реализация SHA-1 на JavaScript. Я также реализовал SHA-512 и SHA-3/Keccak.

    Если вас интересует шифрование, а не криптографический хеш-алгоритм, посмотрите на мою реализацию TEA (Tiny Encryption Algorithm) на JavaScript или реализацию AES на JavaScript.

    Обратите внимание, что эти скрипты предназначены для помощи в изучении алгоритмов, а не для производственного использования. Для производственного использования я бы рекомендовал API веб-криптографии для браузера (см. пример) или криптографическую библиотеку в Node.js. Для хеширования паролей у меня есть пример WebCrypto с использованием PBKDF2.

    См. ниже исходный код реализации JavaScript, также доступный на GitHub. §Номера разделов связывают код с разделами стандарта. Примечание. Я использую греческие буквы в «логических функциях», как представлено в спецификации (если у вас возникнут какие-либо проблемы, убедитесь, что вы включили ).

    Благодаря своему нетипизированному синтаксису в стиле C JavaScript удивительно близок к псевдокоду: раскрывает алгоритмы с минимумом синтаксических отвлекающих факторов. Эти функции должны быть простыми для перевода на другие языки, если это необходимо, хотя их также можно использовать как есть в браузерах и Node.js.

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

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

    Узнайте, как архитектура подписи хэшей на стороне клиента может ускорить цифровые подписи в вашей ИТ-среде.

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

    Как обеспечить безопасность всех цифровых подписей для полностью удаленных сотрудников без ущерба для производительности?

    Цифровые подписи для распределенных команд

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

    Что касается включения цифровых подписей для распределенной команды, существует три основных подхода:

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

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

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

    Вариант 3 — оптимальное решение, если его можно реализовать при сохранении отличной производительности. Здесь в игру вступает хэш-подпись.

    Что такое хэш-подпись?

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

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

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

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

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

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

    Примеры SegWit-транзакций:

    Все примеры изображений, предоставленные для этой транзакции:

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

    Пример для транзакции без SegWit, ввод знаков с индексом 0:

    Пример транзакции SegWit, ввод знаков с индексом 0:

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

    Если входной индекс подписи совпадает с несуществующим выходным, возникает исключение, в котором хэш шаблона возвращает значение 1. Подписание входных данных с хэшем из прообраза равным 1 приведет к компрометации закрытого ключа.

    Пример транзакции без использования SegWit, входные данные подписаны индексом 1:

    Пример транзакции SegWit, ввод знаков с индексом 0:

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

    Пример для транзакции без SegWit, ввод знаков с индексом 0:

    Пример транзакции SegWit, ввод знаков с индексом 0:

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

    Пример для транзакции без SegWit, ввод знаков с индексом 0:

    Пример транзакции SegWit, ввод знаков с индексом 0:

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

    Читайте также: