Какова разница между SSH ключами для сервера? — Хабр Q&A

В чем разница между ключами rsa, dsa и ecdsa, которые использует ssh? — ssh

Вам все они нужны?
Нет, вашему ssh-серверу нужен только один, а клиенту нужно только поддерживать этот тип ключа для ssh-соединений.


RSA, DSA, ECDSA, EdDSA и Ed25519 все используются для цифровой подписи, но только RSA также может использоваться для шифрования.

RSA ( Rivest-Shamir-Adleman) является одной из первых криптосистем с открытым ключом и широко используется для безопасной передачи данных. Его безопасность зависит от целочисленной факторизации, поэтому безопасный ГСЧ никогда не нужен. По сравнению с DSA RSA быстрее для проверки подписи, но медленнее для генерации.

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

ECDSA ( алгоритм цифровой подписи эллиптической кривой) является реализацией алгоритма цифровой подписи DSA (эллиптической кривой). Криптография с эллиптической кривой способна обеспечить относительно тот же уровень безопасности, что и RSA, с меньшим ключом. Это также разделяет недостаток DSA в том, что он чувствителен к плохим RNG.

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

Ed25519, схема подписи EdDSA, но с использованием SHA-512/256 и Curve25519; это безопасная эллиптическая кривая, которая обеспечивает лучшую безопасность, чем DSA, ECDSA и EdDSA, плюс имеет лучшую производительность (не заметно для человека).


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

ECDSA, (представленная в OpenSSH v5.7), вычислительно легче, чем DSA, но разница не заметна, если у вас нет машины с очень низкой вычислительной мощностью.

Начиная с OpenSSH 7.0, SSH больше не поддерживает ключи DSA (ssh-dss) по умолчанию. Ключ DSA используется для работы везде, в соответствии со стандартом SSH (RFC 4251 и последующие).

Ed25519 был введен в oepnSSH 6.5.

Гостевая статья — цифровые подписи, ecdsa и eddsa

Цифровые подписи

— это криптографический инструмент для

подписи сообщений

и

проверки подписей сообщений

с целью подтверждения

подлинности

цифровых сообщений или электронных документов. Цифровые подписи обеспечивают:

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

Цифровые подписи

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

Цифровые подписи

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

цифровых подписей

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

Подписывать сообщения и проверять подписи: как это работает?
Схемы цифровой подписи

обычно используют криптосистему с

открытым ключом

(например, RSA или ECC) и используют

пары открытый / закрытый ключи.

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

Сообщения

подписываются

отправителем с использованием

закрытого ключа

(ключа подписи). Обычно входное сообщение

хэшируется

, а затем

подпись

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

цифровая подпись

(одно или несколько целых чисел):

signMsg(msg, privKey) 🡒 signature

Подписи

сообщений

проверяются

соответствующим открытым ключом

(ключом проверки). Обычно подписанное сообщение

хэшируется

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

verifyMsgSignature(msg, signature, pubKey) 🡒 valid / invalid
Подпись сообщения

математически гарантирует, что определенное сообщение было подписано определенным (секретным)

закрытым ключом,

который соответствует определенному (не секретному)

открытому ключу

. После того, как сообщение подписано,

сообщение и подпись не могут быть изменены

, и, таким образом,

аутентификация

и

целостность

сообщения гарантируются. Любой, кто знает

открытый ключ

подписавшего сообщения,

может проверить подпись

. После подписания автор не может отказаться от акта подписания (это известно как

отказ от авторства

).

Большинство схем подписи работают так, как показано на следующей диаграмме:

При

подписании

входное сообщение

хэшируется

(либо отдельно, либо вместе с открытым ключом и другими входными параметрами), затем некоторое

вычисление

(на основе эллиптических кривых, дискретных логарифмов или другого криптографического примитива) вычисляет

цифровую подпись

. Полученное

подписанное сообщение

состоит из исходного сообщения вычисленной подписи.

При

проверке подписи сообщение

для проверки

хэшируется

(либо отдельно, либо вместе с открытым ключом), и выполняются некоторые вычисления между

хешем

сообщения,

цифровой подписью

и открытым

ключом

, и, наконец, сравнение решает, действительна ли подпись или нет ,

Цифровые подписи

отличаются от

КАС

(кодов аутентификации сообщений), поскольку MAC создаются и проверяются одним и тем же секретным ключом с использованием

симметричного алгоритма

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

асимметричного алгоритма

. И подписи, и коды КAС обеспечивают аутентификацию и целостность сообщений.

Схемы и алгоритмы цифровой подписи

Большинство криптосистем с открытым ключом, таких как

RSA

и

ECC

, предоставляют безопасные схемы цифровой подписи (алгоритмы подписи). Примерами хорошо известных схем цифровой подписи являются:

DSA, ECDSA, EdDSA, подписи RSA, подписи Эль-Гамаля и подписи Шнорра.

Вышеупомянутые схемы подписи основаны на сложности

DLP

(проблема дискретного логарифма) и

ECDLP

(проблема дискретного логарифма эллиптической кривой) и

являются квантово-разрушаемыми

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

Квантово-безопасные подписи

(такие как

SPHINCS, BLISS и XMSS

) не используются массово из-за большой длины ключа, длинных подписей и более низкой производительности по сравнению с ECDSA и EdDSA.

Наиболее популярные схемы цифровой подписи (по состоянию на ноябрь 2021 г.): подписи

RSA, ECDSA и EdDSA

. Давайте дадим некоторые подробности о них, а также некоторые примеры кода.

Подписи RSA

Криптосистема с открытым ключом

RSA

предоставляет криптографически б

езопасную схему цифровой подписи

(sign verify), основанную на математике модульных возведения в степень и дискретных логарифмах и сложности

задачи целочисленной факторизаци

и (ЗЦФ). Процесс

подписи / проверки RSA

работает следующим образом:

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

Подписи RSA являются

детерминированными

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

Подписи RSA

широко используются в современной криптографии, например, для подписания цифровых сертификатов для защиты веб-сайтов. Например (по состоянию на ноябрь 2021 г.) официальный веб-сайт Microsoft использует Sha256RSA для своего цифрового сертификата. Тем не менее, в последнее десятилетие наблюдается тенденция перехода от RSA и DSA

Читайте также:  Назначение защищенного носителя для хранения ЭЦП и его преимущества | Новости Бухгалтер 911

к подписям на основе эллиптических кривых

(например, ECDSA и EdDSA). Современные криптографы и разработчики

предпочитают подписи ECC

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

DSA (алгоритм цифровой подписи)

DSA (алгоритм цифровой подписи) — это криптографически безопасный стандарт для

цифровых подписей

(подписывание сообщений и проверка подписи), основанный на математике

модульных возведений

в степень и дискретных логарифмов и сложности проблемы дискретного логарифма (DLP). Это альтернатива RSA и используется вместо RSA из-за ограничений патентов с RSA (до сентября 2000 года).

DSA

является вариантом схемы подписи Эль-Гамаля.

Процесс подписи / проверки DSA

работает следующим образом:

  • Алгоритм подписи DSA вычисляет хеш сообщения, затем генерирует случайное целое число k и вычисляет подпись (пара целых чисел {r, s}), где r вычисляется из k, а s вычисляется с использованием хеша сообщения показатель частного ключа случайное число k. Из-за случайности подпись недетерминирована.
  • Алгоритм проверки подписи DSA включает вычисления, основанные на хэше сообщения показатель открытого ключа подпись {r, s}.

Случайное

значение k

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

k

и одного и того же

закрытого ключа

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

tintinweb/ecdsa-private-key-recovery

).

Вариант

детерминированного DSA

определен в

RFC 6979

, который вычисляет случайное число

k

как

HMAC

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

Детерминированный DSAсчитается более безопасным.

В современной криптографии подписи

на основе эллиптических кривых

(например, ECDSA и EdDSA) предпочтительнее DSA из-за более короткой длины ключа, более короткой длины подписи, более высокого уровня безопасности (для той же длины ключа) и лучшей производительности.

ECDSA (алгоритм цифровой подписи эллиптической кривой)

ECDSA (алгоритм цифровой подписи эллиптической кривой) представляет собой криптографически безопасную схему

цифровой подписи

, основанную на криптографии с эллиптической кривой (ECC).

ECDSA

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

ECDSA

— это адаптация классического алгоритма

DSA

, который основан на схеме подпись Эль-Гамаля. Точнее, алгоритм ECDSA представляет собой вариант

подпись Эль-Гамаля

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

эллиптическую кривую

(например, secp256k1),

закрытый ключ

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

Процесс подписи / проверки ECDSA

работает следующим образом:

  • Алгоритм подписания ECDSA вычисляет хэш сообщения, затем генерирует случайное целое число k и вычисляет подпись (пара целых чисел {r, s}), где r вычисляется из k, а s вычисляется с использованием хеша сообщения закрытый ключ случайное число k . Из-за случайности подпись недетерминирована.
  • Алгоритм проверки подписи ECDSA включает вычисления, основанные на хэше сообщения открытый ключ подпись {r, s}.

Случайное значение k

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

k

и одного и того же з

акрытого ключа

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

tintinweb/ecdsa-private-key-recovery

).

Вариант

детерминированного ECDSA

определен в

RFC 6979

, который вычисляет случайное число

k

как

HMAC

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

Детерминированный ECDSA считается более безопасным.
Подписи ECDSA

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

EdDSA (алгоритм цифровой подписи Эдвардса)
EdDSA

(алгоритм цифровой подписи кривой Эдвардса) — это быстрый алгоритм

цифровой подписи

, использующий

эллиптические кривые в форме Эдвард

са (например,

Ed25519

и

Ed448-Goldilocks

), детерминированный вариант схемы п

одписи Шнорра

, разработанный командой известного криптографа.

Даниэль Бернштейн.
EdDSA

является более

простым

, чем

ECDSA

, более

безопасным

, чем

ECDSA

, и предназначен для работы

быстрее

, чем

ECDSA

(для кривых с сопоставимой длиной ключа). Как и

ECDSA

, схема подписей

EdDSA

основывается на

сложности задачи ECDLP

(проблема дискретного логарифма с эллиптической кривой) в плане надежности.

Алгоритм подписи EdDSA

работает с эллиптическими кривыми Эдвардса, такими как

Curve25519

и

Curve448

, которые высоко

оптимизированы

для производительности и

безопасности

. Показано, что подписи

Ed25519

обычно

быстрее

, чем традиционные

подписи ECDSA

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

подписи / проверки EdDSA

работает следующим образом:

  • Алгоритм подписи EdDSA генерирует детерминированное (не случайное) целое число r (вычисляется путем хеширования сообщения и хэша секретного ключа), а затем вычисляет подпись {Rs, s}, где Rs вычисляется из r, а s вычисляется из хеш (сообщение открытый ключ, полученный из частного число r) закрытый ключ. Подпись является детерминированной (одно и то же сообщение, подписанное одним и тем же ключом, всегда дает одну и ту же подпись).
  • Алгоритм проверки подписи EdDSA включает вычисления эллиптической кривой на основе сообщения (хешированного вместе с открытым ключом и точкой EC Rs из подписи) открытый ключ число s из подписи {Rs, s}.

По своей сути подписи

EdDSA

являются

детерминированными

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

Краткое сравнение между подписей

EdDSA Ed25519

и

ECDSA secp256k

приведено ниже:

Современные разработчики часто используют

подписи Ed25519

вместо 25

6-битных кривых ECDSA

, потому что схема подписи EdDSA-Ed25519 использует ключи, которые умещаются в 32 байта (64 шестнадцатеричных цифры), подписи умещаются в 64 байта (128 шестнадцатеричных цифр), подпись и проверка быстрее и безопасность считается лучше.

Публичные

цепочки блоков

(например, Биткойн и Эфириум) часто используют подписи

ECDSA

на основе

secp2561

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

В общем случае, считается, что

подписиEdDSA рекомендуется ECDSA

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

Другие схемы подписи и алгоритмы

Большинство алгоритмов подписи основаны на общих схемах подписи, таких как

подписи Эль-Гамаля и подписи Шнорра.

  • Подпись RSA получена из схемы шифрования RSA.
  • DSA и ECDSA основаны на схеме подписи ElGamal.
  • EdDSA является производной от схемы подписи Шнорра.

Другие

схемы подписи

включают в себя:

  • ECGDSA: схема цифровой подписи с эллиптической кривой (основанная на сложности проблемы ECDLP), слегка упрощенный вариант ECDSA, известный как немецкая версия ECDSA.
  • ECKDSA: схема цифровой подписи с эллиптической кривой (основанная на сложности проблемы ECDLP), сложный вариант ECDSA, известный как корейская версия ECDSA. ECKDSA подписывает данное сообщение с помощью закрытого ключа EC вместе с хешем цифрового сертификата подписавшего. Это добавляет идентичность к цифровой подписи, в дополнение к аутентификации сообщения, целостности и невозможности отказа.
  • Подпись SM2: схема цифровой подписи с эллиптической кривой (основанная на сложности задачи ECDLP), известная как китайский алгоритм цифровой подписи, разработанный Китайской академией наук.
  • ГОСТ Р 34.10-2001: схема цифровой подписи с эллиптической кривой (основанная на сложности задачи ECDLP), известная как российский алгоритм цифровой подписи, один из российских стандартных алгоритмов криптографии (называемых алгоритмами ГОСТ).
Читайте также:  Должностная инструкция тендерного специалиста — пример 2020 и 2021

После краткого обзора самых популярных алгоритмов цифровой подписи давайте познакомимся с техническими подробностями о алгоритмах

подписи RSA, ECDSA и EdDSA

с примерами кода.

Источник

Какова разница между ssh ключами для сервера?

Товарищи, многим известны генераторы ключей, например PuTTY Keygen, и они позволяют сформировать разные типы пар ключей:

SSH-1 (RSA)
SSH-2 RSA
SSH-2 DSA

Вопросов аж несколько:

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

2. В чем отличие между этими ключами? (желательно на пальцах, т.к. я новичок)

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

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

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

Ключевые термины

DSS (Digital Signature Standard) – стандарт США на цифровую подпись. В основе стандарта лежит алгоритм, называемый DSA (Digital Signature Algorithm) и являющийся вариацией подписи Эль-Гамаля.

ГОСТ Р34.10-2001 – новый российский стандарт на алгоритм формирования и проверки ЭЦП. Основан на сложности взятия дискретного логарифма в группе точек эллиптической кривой, а также на стойкости хэш-функции по ГОСТ Р34.11-94. Размер формируемой цифровой подписи – 512 бит.

ГОСТ Р34.10-94 – российский стандарт на алгоритм формирования и проверки ЭЦП, действующий с 1995 года. В стандарте используется модификация схемы шифрования с открытым ключом Эль-Гамаля и алгоритм выработки хэш-функции по ГОСТ Р34.11-94.

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

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

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

Новый отечественный стандарт эцп

В 2001 г. был принят новый отечественный стандарт на алгоритм формирования и проверки ЭЦП. Его полное название следующее: «ГОСТ Р34.10-2001. Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи».

Данный алгоритм был разработан главным управлением безопасности связи Федерального агентства правительственной связи и информации при Президенте Российской Федерации при участии Всероссийского научно-исследовательского института стандартизации. Новый стандарт разрабатывался с целью обеспечения большей стойкости алгоритма генерации ЭЦП.

В основе ГОСТ Р34.10-2001 лежат алгоритмы с использованием операций на эллиптических кривых. Стойкость ГОСТ Р34.10-2001 основывается на сложности взятия дискретного логарифма в группе точек эллиптической кривой, а также на стойкости хэш-функции по ГОСТ Р34.11-94. Размер формируемой цифровой подписи – 512 бит.

В целом алгоритм вычислений по алгоритму ГОСТ Р34.10-2001 аналогичен применяемому в предыдущем стандарте ГОСТ Р34.10-94. Сначала генерируется случайное число k, с его помощью вычисляется компонента r подписи.

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

Старый ГОСТ Р34.10-94 не отменен, и в настоящее время параллельно действуют два отечественных стандарта на ЭЦП. Однако необходимо отметить, что для прежнего ГОСТа принято ограничение: при реализации ЭЦП по стандарту ГОСТ Р34.10-94 разрешено использовать только 1024-битные значения параметра p.

Использование математического аппарата группы точек эллиптической кривой в новом ГОСТ Р34.10-2001 позволяет существенно сократить порядок модуля p без потери криптостойкости. Так, в стандарте указано, что длина числа р может быть 256 или больше бит.

Повышаем защиту ключа с использованием pkcs#8

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

Для ssh-ключей существует несколько стандартов с неуклюжими названиями:

Я не знаю, почему

ssh-keygen

до сих пор генерирует ключи в традиционном формате, несмотря на то, что уже много лет существуют лучшие альтернативы. Дело не в совместимости с серверным софтом: закрытые ключи никогда не покидают пределы вашего компьютера. К счастью, существующие ключи достаточно легко преобразовать в формат PKCS#8:

$ mv test_rsa_key test_rsa_key.old
$ openssl pkcs8 -topk8 -v2 des3 
    -in test_rsa_key.old -passin 'pass:super secret passphrase' 
    -out test_rsa_key -passout 'pass:super secret passphrase'


Если попробовать использовать новый файл ключа в формате PKCS#8, можно обнаружить, что все работает так же как и раньше. Посмотрим, что теперь находится внутри файла.

$ cat test_rsa_key
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIFDjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQIOu/S2/v547MCAggA
MBQGCCqGSIb3DQMHBAh4q o4ELaHnwSCBMjA ho9K816gN1h9MAof4stq0akPoO0
CNvXdtqLudIxBq0dNxX0AxvEW6exWxz45bUdLOjQ5miO6Bko0lFoNUrOeOo/Gq4H
dMyI7Ot1vL9UvZRqLNj51cj/7B/bmfa4msfJXeuFs8jMtDz9J19k6uuCLUGlJscP
    ... десу-десу ...
-----END ENCRYPTED PRIVATE KEY-----

Обратите внимание на то, что первая и последняя строки изменились (

BEGIN ENCRYPTED PRIVATE KEY

вместо

BEGIN RSA PRIVATE KEY

), а заголовки

Proc-TypeDEK-Info

исчезли. Фактически, в файле хранятся данные во все том же формате ASN.1:

$ openssl asn1parse -in test_rsa_key
    0:d=0  hl=4 l=1294 cons: SEQUENCE
    4:d=1  hl=2 l=  64 cons: SEQUENCE
    6:d=2  hl=2 l=   9 prim: OBJECT            :PBES2
   17:d=2  hl=2 l=  51 cons: SEQUENCE
   19:d=3  hl=2 l=  27 cons: SEQUENCE
   21:d=4  hl=2 l=   9 prim: OBJECT            :PBKDF2
   32:d=4  hl=2 l=  14 cons: SEQUENCE
   34:d=5  hl=2 l=   8 prim: OCTET STRING      [HEX DUMP]:3AEFD2DBFBF9E3B3
   44:d=5  hl=2 l=   2 prim: INTEGER           :0800
   48:d=3  hl=2 l=  20 cons: SEQUENCE
   50:d=4  hl=2 l=   8 prim: OBJECT            :des-ede3-cbc
   60:d=4  hl=2 l=   8 prim: OCTET STRING      [HEX DUMP]:78ABEA3810B6879F
   70:d=1  hl=4 l=1224 prim: OCTET STRING      [HEX DUMP]:C0FA1A3D2BCD7A80DD61F4C0287F8B2D...


Воспользуемся

, чтобы рассмотреть структуру ASN.1:

Sequence (2 elements)
|- Sequence (2 elements)
|  |- Object identifier: 1.2.840.113549.1.5.13            // using PBES2 from PKCS#5
|  `- Sequence (2 elements)
|     |- Sequence (2 elements)
|     |  |- Object identifier: 1.2.840.113549.1.5.12      // using PBKDF2 — yay! :)
|     |  `- Sequence (2 elements)
|     |     |- Byte string (8 bytes): 3AEFD2DBFBF9E3B3    // salt
|     |     `- Integer: 2048                              // iteration count
|     `- Sequence (2 elements)
|          Object identifier: 1.2.840.113549.3.7          // encrypted with Triple DES, CBC
|          Byte string (8 bytes): 78ABEA3810B6879F        // initialization vector
`- Byte string (1224 bytes): C0FA1A3D2BCD7A80DD61F4C0287F8B2DAB46A43E...  // encrypted key blob

Здесь упоминаются OID (Object identifier) — глобально-уникальные цифровые идентификаторы. По ним мы узнаем, что используется схема шифрования

, функция получения ключа

и алгоритм шифрования

. Функция хеширования не указана явно, значит,

используется

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

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

Читайте также:  Перенос КриптоПро, ключей ЭЦП, сертификатов с одного компьютера на другой - Trust Me I`m an Engineer

Пример создания и проверки подписи по стандарту гост р34.10-94

Пусть p = 23, q = 11, a =6 (проверяем: 611 mod 23 = 1 )

Создание подписи.

Предположим, пользователь А выбрал в качестве закрытого ключа число х=8. После этого он вычисляет открытый ключ по формуле y = аx mod p. То есть y = 68 mod 23 = 18.

Для создания подписи пользователь А выбирает случайное число k = 5.

Пусть результат вычисления хеш-функции для сообщения H(m) = 9.

Подпись сообщения состоит из двух чисел (r, s):

Таким образом, подпись сообщения состоит из пары чисел (2, 6).

Проверка подписи.

Получив сообщение вместе с подписью (2, 6), получатель вычисляет

Так как v = r, то подпись считается верной.

Подписи, созданные с использованием стандартов ГОСТ Р34.10 или DSS, так же, как и подписи, полученные по алгоритму Эль-Гамаля, являются рандомизированными, так как для одинаковых сообщений с использованием одного и того же закрытого ключа х каждый раз будут создаваться разные подписи (r,s) благодаря использованию разных случайных значений k.

Симметричная или асимметричная криптография?

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

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

  1. Алгоритмы с открытым ключом работают намного (в сотни раз) медленнее классических алгоритмов с закрытым ключом. Это их самый главный недостаток. Связан он с тем, что основной операцией в системах с открытым ключом является возведение в степень по большому модулю 500-1000 битовых чисел, что при программной реализации производится намного медленнее, чем шифрование того же объема данных классическими способами.
  2. Алгоритмы с открытым ключом требуют обеспечения достоверности открытых ключей, что порой превращается в довольно сложную задачу. То же самое относится и к протоколам цифровой подписи. Для управления открытыми ключами используют специальную инфраструктуру открытых ключей, обеспечивающую функции управления открытыми ключами.
  3. Алгоритмы с открытым ключом чувствительны к атакам по выбранному открытому тексту.

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

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

  1. Пользователь А генерирует случайный сеансовый ключК и зашифровывает им с помощью симметричного алгоритмаFсим свое сообщение M:
  2. Пользователь А получает из базы данных открытый ключ U пользователя Б и зашифровывает им сеансовый ключК:
  3. Пользователь А посылает своему абоненту зашифрованное сообщение и зашифрованный сеансовый ключCk. Для защиты от вскрытия «человек-в-середине» передаваемые данные могут быть дополнены цифровой подписью.
  4. Пользователь Б расшифровывает полученный сеансовый ключCk с помощью своего закрытого ключа R:
  5. Пользователь Б расшифровывает сообщение с помощью сеансового ключа К:

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

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

Стандарт цифровой подписи гост р34.10-94

В России принят стандарт ГОСТ Р34.10-94 «Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма». В этом стандарте используется алгоритм, аналогичный алгоритму, реализованному в стандарте DSS.

Вначале, так же как и по стандарту DSS, для группы абонентов выбираются три общих (несекретных) параметра р, q и a:

Подпись сообщения m состоит из двух чисел (r, s), вычисляемых по следующим формулам:

где H(m) – результат вычисления хеш-функции для сообщения m.

На этом формирование подписи закончено, и сообщение m вместе с ЭЦП (r,s) может быть отправлено получателю. Теперь отметим отличия алгоритма формирования ЭЦП по ГОСТ Р34.10-94 от алгоритма DSS.

1. Перед вычислением подписи исходное сообщение обрабатывается разными функциями хеширования: в ГОСТ Р34.10-94 применяется отечественный стандарт на хеш-функцию ГОСТ Р34.11-94, в DSS используется SHA-1, которые имеют разную длину хеш-кода. Отсюда и разные требования на длину простого числа q: в ГОСТ Р34.

2. По-разному вычисляется компонента s подписи. В ГОСТ Р34.10-94 компонента s
вычисляется по формуле

а в DSS компонента s вычисляется по формуле

Последнее отличие приводит к соответствующим отличиям в формулах для проверки подписи.

В результате процедура проверки подписи по ГОСТ Р34.10-94 заключается в следующем. Получив [m, (r, s)], получатель вычисляет

Затем проверяется равенство вычисленного значения v и полученного в составе ЭЦП параметра r. Подпись считается корректной, если v = r.

В алгоритме создания ЭЦП по ГОСТ Р34.10-94, так же как и в алгоритме DSS, производятся достаточно сложные вычисления, требующие затрат вычислительных ресурсов. Для ускорения процесса генерации подписей по этим алгоритмам можно заранее вычислять некоторое количество значений параметра r, не зависящего от подписываемого сообщения.

Формат закрытого ключа, защищенного паролем


Теперь усложним жизнь потенциальному злоумышленнику, который смог украсть закрытый ключ — защитим его паролем. Что произошло с файлом?

$ ssh-keygen -t rsa -N 'super secret passphrase' -f test_rsa_key
$ cat test_rsa_key
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,D54228DB5838E32589695E83A22595C7

3 Mz0A4wqbMuyzrvBIHx1HNc2ZUZU2cPPRagDc3M rv XnGJ6PpThbOeMawz4Cbu
lQX/Ahbx UadJZOFrTx8aEWyZoI0ltBh9O5 ODov vc25Hia3jtayE51McVWwSXg
wYeg2L6U7iZBk78yg sIKFVijxiWnpA7W2dj2B9QV0X3ILQPxbU/cRAVTd7AVrKT
    ... и так далее ...
-----END RSA PRIVATE KEY-----

Заметим, что добавились две строки с заголовками, а результат декодирования Base64-строки больше не является валидным ASN.1. Дело в том, что структура ASN.1. зашифрована. Из заголовков узнаем, какой алгоритм использовался для шифрования:

в режиме CBC. 128-битная шестнадцатеричная строка в заголовке

DEK-Info

— это вектор инициализации (IV). Ничего необычного здесь нет, все распространенные криптографические библиотеки умеют работать с используемыми здесь алгоритмами.

Но как из пароля получается ключ AES? Я не нашел этого в документации и поэтому был вынужден разбираться в исходниках OpenSSL. Вот что я выяснил насчет получения ключа шифрования:

  1. Первые 8 байт вектора инициализации дописываются к паролю (по сути, являются солью).
  2. От полученной строки один раз берется MD5-хеш.

Для проверки расшифруем закрытый ключ, взяв вектор инициализации из заголовка

DEK-Info

$ tail -n  4 test_rsa_key | grep -v 'END ' | base64 -d | 
  openssl aes-128-cbc -d -iv D54228DB5838E32589695E83A22595C7 -K $(
    ruby -rdigest/md5 -e 'puts Digest::MD5.hexdigest(["super secret passphrase",0xD5,0x42,0x28,0xDB,0x58,0x38,0xE3,0x25].pack("a*cccccccc"))'
  ) |
  openssl asn1parse -inform DER

Эта команда выведет параметры ключа RSA. Если вы хотите просто увидеть ключ, есть способ и проще:

$ openssl rsa -text -in test_rsa_key -passin 'pass:super secret passphrase'

Но я хотел показать, как именно ключ AES получается из пароля, чтобы обратить внимание на два уязвимых места:

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

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

Adblock
detector