Криптоалгоритмы. классификация с точки зрения количества ключей

Краткое содержание

Ожидаемая необходимость новых криптографических стандартов от НИСТ (Национального Института Стандартов и Технологий США) означает выведение из использования 1024-битного RSA и 160-битной криптографии на эллиптических кривых (ECC) в конце 2010 года. Данные описания комментируют уязвимости этих систем к попыткам атак со стороны открытого сообщества и имеют своей целью оценить риск их неизбежного использования после 2010 года пока не будет завершена миграция на новые стандарты. Мы пришли к заключению что для 1024-битного RSA риск невелик по крайней мере до 2014 года, а также 160-битная ECC над полем простого числа может быть безопасно использована значительно дольше — при текущем состоянии дел в криптоанализе мы будем удивлены, если усилия открытого сообщества поставят под угрозу 160-битную ECC над полем простого числа до 2020 года. Наша оценка основана на последних практических данных попыток широкомасштабной целочисленной факторизации и вычисления дискретного логарифма в эллиптических кривых.

Безопасно ли шифрование RSA на будущее??

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

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

Brayan Jackson Administrator
Sorry! The Author has not filled his profile.

Генерирование запроса на подпись сертификата

Генерирование закрытого ключа и запроса

Этот метод позволяет вам подписать сертификат в ЦС и защитить веб-сервер Apache или Nginx с помощью HTTPS. Сгенерированный запрос на подпись можно отправить в ЦС, чтобы получить подписанный сертификат. Если ЦС поддерживает SHA-2, добавьте опцию -sha256.

Следующая команда создаст 2048-битный закрытый ключ (domain.key) и CSR (domain.csr):

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

Опция -newkey rsa:2048 создаст 2048-битный RSA-ключ. Опция –nodes отключает пароль для закрытого ключа.

Генерирование запроса для существующего закрытого ключа

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

Следующая команда создаст запрос сертификата (domain.csr) для существующего ключа (domain.key):

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

Генерирование запроса для существующего сертификата и ключа

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

Следующая команда создаст запрос (domain.csr) на основе существующего сертификата (domain.crt) и закрытого ключа (domain.key):

Опция -x509toreq создаст сертификат X509.

Цифровые сертификаты[править]

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

Способы получения SSL-сертификата:

• Использовать самоподписанный сертификат
• Использовать «пустой» сертификат

Самоподписанный сертификат — сертификат, созданный самим пользователем — в этом случае издатель сертификата совпадает с владельцем сертификата. «Пустой» сертификат — сертификат, содержащий фиктивную информацию, используемую в качестве временной для настройки SSL и проверки его функциональности в данной среде.

Устройство протокола SSL[править]

Работу протокола можно разделить на два уровня:

• Слой протокола подтверждения подключения (Handshake Protocol Layer)
• Слой протокола записи

Первый слой, в свою очередь, состоит из трех подпротоколов:

• Протокол подтверждения подключения (Handshake Protocol)
• Протокол изменения параметров шифра (Cipher Spec Protocol)
• Предупредительный протокол (Alert Protocol)

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

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

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

Протокол записиправить

Протокол записи (Record Layer) — это уровневый протокол. На каждом уровне сообщения включают поля для длины, описания и проверки. Протокол записи принимает сообщения, которые нужно передать, фрагментирует данные в управляемые блоки, разумно сжимает данные, применяя MAC (message authentication code), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента.

Существует четыре протокола записи:

• Протокол рукопожатия (handshake protocol);
• Протокол тревоги (alert protocol);
• Протокол изменения шифра (the change cipher spec protocol);
• Протокол приложения (application data protocol);

Как взламывают алгоритм RSA?

RSA – это изученный метод шифрования, который можно взломать несколькими способами. Самым эффективным является поиск закрытого ключа, который позволяет открыть информацию из открытого ключа. Позволяет получать всю информацию, которая была зашифрованной, также внедряться в код подписи, подделывая ее. Для проведения атаки необходимо найти сомножители общего модуля n – p и q. Благодаря данным p, q, e, хакер может без проблем получить частный показатель d. Основная трудность метода – поиск сомножителей. В основе безопасности лежит схема определения множителей, что позволяет создать задачу без эффективных вариантов решения.

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

Следующая возможность взлома заключается в поиске способа определения корня степени e из mod n. Если злоумышленник получит корень из уравнения C = Me, то он получает доступ к зашифрованным сообщениям и возможность подделки подписи без знания приватного ключа. Сегодня не получается узнать схему, благодаря которой алгоритм взламывается подобным способом.

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

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

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

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

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

Как SSL-сертификат помогает защитить данные?

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

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

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

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

е. расшифровать закрытым ключом.

Инструменты

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

Инструмент	Назначение
New-SelfSignedCertificate	Создает самозаверяющие сертификаты.
makecert	Создает сертификаты. Вместо него рекомендуется использовать New-SelfSignedCertificate.
sn	Создает строгие имена для симметричных ключей.

Разъяснение внешних компонент

Более пятилетки назад, еще в 2015 году я написал свою внешнюю компоненту на Visual Basic 6. По сути, это была простая обертка для доступа к функция DLL. Потом написал еще одну обертку уже для другой DLL, от другого оборудования. На этом моё писательство внешних компонент и ограничилось.

И вот в 2020 году существенно изменилось SDK оборудования, для которого было написано SDK. А Visual Basic прекратил свое существование. На нем еще можно писать внешние компоненты, но уже только под 32 разряда. Пришлось искать новые средства для разработки, поддерживающие 64-разрядные платформы.

И на этом пути пришлось потратить более 6 часов для выбора инструмента и его настройки.

1 стартмани

Создание корневого приватного ключа

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

Генерация приватного ключа RSA используя параметры по умолчанию (ключ будет сохранён в файл с именем rootCA.key):

openssl genpkey -algorithm RSA -out rootCA.key

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

Для безопасности ключа его следует защитить паролем. Генерация приватного ключа RSA используя 128-битное AES шифрование (-aes-128-cbc) и парольную фразу «hello» (-pass pass:hello):

openssl genpkey -algorithm RSA -out rootCA.key -aes-128-cbc -pass pass:hello

Конечно, опцию -pass pass:hello можно не указывать, тогда вам будет предложено ввести пароль во время генерации ключа.

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

man enc

Если для генерируемого ключа не указано количество бит, то по умолчанию используется 2048, вы можете указать другое количество бит с помощью команды вида (будет создан 4096-битный ключ):

openssl genpkey -algorithm RSA -out rootCA.key -aes-128-cbc -pkeyopt rsa_keygen_bits:4096

Создание самоподписанного корневого сертификата

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 1024 -out rootCA.crt

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

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

Ответ 1

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

.csr — Это запрос на подписание сертификата. Некоторые приложения могут генерировать их для отправки в центры сертификации. Фактический формат — PKCS10, который определен в RFC 2986. Он включает некоторые/все ключевые детали запрашиваемого сертификата, такие как субъект, организация, штат и т.д., а также открытый ключ сертификата, который должен быть подписан. Сначала его необходимо подписать в центре сертификации. Возвращенный сертификат — это открытый сертификат (который включает открытый ключ, но не закрытый ключ), который сам может быть в нескольких форматах.

.pem — определенный в RFC с 1421 по 1424, это контейнерный формат, который может включать только открытый сертификат (как, например, при установке Apache и файлов сертификатов CA /etc/ssl/certs),  или может включать всю цепочку сертификатов, включая открытый ключ, закрытый ключ и корневые сертификаты. Настораживает то, что он также может быть закодирован в CSR, Поскольку формат PKCS10 может быть переведен в PEM. Название происходит от Privacy Enhanced Mail (PEM), неудачного метода для безопасной электронной почты. Но формат контейнера, который он использовал, продолжает жить и является переводом x509 ASN.1 ключей в base64.

.key — Это файл в формате PEM, содержащий только закрытый ключ конкретного сертификата, и это просто условное, а не стандартизированное название. В установках Apache он часто находится в каталоге /etc/ssl/private. Права на эти файлы очень важны, и некоторые программы откажутся загружать эти сертификаты, если они установлены неправильно.

.pkcs12 .pfx .p12 — Первоначально определенный RSA в Стандартах криптографии открытых ключей (сокращенно PKCS), вариант «12» был первоначально усовершенствован Microsoft, а затем представлен как RFC 7292. Это формат контейнера с паролем, который содержит пары публичных и приватных сертификатов. В отличие от файлов .pem, этот контейнер полностью зашифрован. OpenSSL может превратить его в файл .pem с открытым и закрытым ключами: 

openssl pkcs12 -in file-to-convert.p12 -out converted-file.pem –nodes

Есть также, несколько других форматов, которые попадаются, время от времени:

.der — способ кодирования синтаксиса ASN.1 в двоичном формате, файл .pem — это просто файл .der, закодированный в Base64. OpenSSL может конвертировать их в .pem (openssl x509 -inform der -in to-convert.der -out converted.pem). Windows воспринимает их как файлы сертификатов. По умолчанию Windows, экспортирует сертификаты как файлы в формате .DER с другим расширением..

.cert .cer .crt — файлы в формате .pem (или редко .der), но с другим расширением, которые распознаются проводником Windows как сертификат, а .pem таковым не является.

.p7b .keystore — Определенный в RFC 2315 как PKCS номер 7, это формат, используемый Windows для обмена сертификатами. Java воспринимает их как нативные, и часто использует .keystore в качестве расширения. В отличие от сертификатов в стиле .pem, этот формат имеет определенный способ включения сертификатов сертификационного пути.

.crl — список отзыва сертификатов. Центры сертификации выпускают их как способ деавторизации сертификатов по истечению срока действия. Иногда их можно загрузить с веб-сайтов центров сертификации.

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

1. PEM — регулируется RFC, используется преимущественно в программах с открытым исходным кодом. Он может иметь различные расширения (.pem, .key, .cer, .cert и т.д.).
2. PKCS7 — Открытый стандарт, используемый Java и поддерживаемый Windows. Не содержит закрытый ключ.
3. PKCS12 — закрытый стандарт Microsoft, который позже был определен в RFC и обеспечивает повышенную безопасность по сравнению с обычным текстовым форматом PEM. Он может содержать закрытый ключ. Он используется преимущественно в системах Windows и может быть свободно преобразован в формат PEM с помощью OpenSSL.
4. DER — родительский формат PEM. Полезно рассматривать его как двоичную версию файла PEM с кодировкой base64. Редко используется за пределами Windows.

Форматы сертификатов

До этого в руководстве рассматривались только сертификаты X.509 с кодированием ASCII PEM. Однако существует множество других форматов. Некоторые форматы позволяют объединить компоненты – ключ, запрос, сертификат – в один файл.

Чтобы конвертировать PEM в DER, используйте такую команду:

Формат DER обычно использует Java.

Конвертация PEM в PKCS7

Чтобы добавить сертификаты PEM (domain.crt и ca-chain.crt) в файл PKCS7 (domain.p7b), введите:

Файлы PKCS7 (также известные как P7B) часто используются в Java Keystores и Microsoft IIS (Windows).

Конвертация to PKCS7 в PEM

Чтобы конвертировать PKCS7 в PEM, введите:

Обратите внимание: файл PKCS7 содержит много компонентов, а именно сертификат и промежуточный сертификат ЦС

Конвертация PEM в PKCS12

Следующая команда позволяет объединить закрытый ключ и сертификат в файл PKCS12.

Программа запросит пароль. Файл PKCS12 позволяет объединить несколько сертификатов в один PEM-файл (domain.crt).

Файлы PKCS12 (или PFX) обычно используются для перемещения наборов сертификатов в Micrsoft IIS (Windows).

Конвертация PKCS12 в PEM

Чтобы конвертировать файл PKCS12 в формат PEM, введите:

Если в файле PKCS12 было несколько объектов (например, ключ и сертификат), все они переместятся в файл PEM.

Конвертировать закрытый ключ в формат PKCS # 1

Приведенные выше примеры выводят закрытый ключ в OpenSSL по умолчанию. PKCS # 8 формат. Если вы знаете, что вам нужно PKCS # 1 вместо этого вы можете передать вывод утилиты OpenSSL PKCS # 12 ее утилите RSA или EC в зависимости от типа ключа. Обе команды ниже выведут файл ключа в формате PKCS # 1:

ECDSA

openssl pkcs12 -in INFILE.p12 -nodes -nocerts | openssl ec -out OUTFILE.key

Примечание: Вы можете увидеть разницу между файлами закрытого ключа PKCS # 8 и PKCS # 1, посмотрев на первую строку текста. В файлах PKCS # 1 будет указан алгоритм:

Файлы PKCS # 8 не показывают алгоритм, а также могут быть зашифрованы:or

Спасибо, что выбрали SSL.com! Если у вас возникнут вопросы, свяжитесь с нами по электронной почте по адресу Support@SSL.com, вызов 1-877-SSL-SECUREили просто нажмите на ссылку чата в правом нижнем углу этой страницы.

Цифровые сертификаты (стандарт X.509)[править]

• Удобный способ показать, что кто-то владеет публичным ключом.
• Выпускаются центрами сертификации (Certificate Authority, CA): GlobalSign, Comodo и др.
• PKI (public key infrastructure) — механизм, регулирующий распространение и использование сертификатов (включая создание, отзыв и проверку подлинности).
• Список доверенных CA поддерживается приложением (у браузеров свои списки).
• Сертификаты подписываются другими сертификатами, что повышает надежность.
• Сертификат может быть отозван. Система поддерживает список таких сертификатов (Certificate Revocation List, CRL). На стороне CA список обновляется каждые несколько часов.

Получение сертификатаправить

1. Пользователь генерирует ключ и посылает запрос серверу CA.
2. CA отвечает сообщением со своим сертификатом.
3. Пользователь собирает данные, необходимые для выдачи сертификата (email, отпечаток ключа и т.д.).
4. Пользователь отправляет данные в CA, зашифровав их публичным ключом CA.
5. CA проверяет полученные данные и отправляет сертификат пользователю.

Структура сертификатаправить

• Собственно сертификат
  • Версия
  • Серийный номер
  • Эмитент (тот, кто выпустил сертификат)
  • Субъект
  • Публичный ключ субъекта
  • Период действия
  • Дополнительные поля
• Алгоритм подписи сертификата
• Значение подписи сертификата

Extra

• Впервые RSA был публично описан в 1977 году, и он все еще силен почти 50 лет спустя. Просто нужно увеличить количество бит, чтобы не отставать от более быстрых компьютеров.
• Существует еще один метод криптографии с открытым ключом, основанный на эллиптических кривых, см. ECDSA (1992).
• Существует огромная разница между возможностями пользователя и злоумышленника. Веб-сервер или мобильный клиент имеют один (маломощный) процессор. У злоумышленника может быть целый центр обработки данных, например, недавно построенный центр обработки данных AWS содержит около 60 000 серверов.
• Невероятно, что одно мобильное устройство может вычислить некоторые математические вычисления за несколько секунд … что миллионы компьютеров не могли даже мечтать угадать за всю жизнь.

Рекомендованный размер ключа

При определении размера ключа требуется опираться от модуля n, являющегося суммой p и q, которые для корректной работы должны иметь примерно равную длину. Если модуль равен 524 битам, то приблизительный размер 262 бита.

1. M = (p+q)/2
2. Если p < q, получаем 0 ≤ м – sqrt (n) ≤ (q — p)2/8p.

Так как p = M*(± ), то значения p и q можно без труда найти, если разность чисел небольшая.

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

Логарифм Rivest стал основой для проведения тестов по безопасности ключей в зависимости от их длины. Полученные данные можно применять и к RSA-шифрованию. Обзор защиты проводится на основании способов определения множителей, которые улучшаются благодаря привлечению дополнительных вычислительных ресурсов. В 1997 году 512-битный ключ можно было вскрыть только при помощи оборудования за 1 000 000 USD, для чего потребовалось бы 8 месяцев. Этот же ключ через два года, можно было вскрыть при помощи того же оборудования, но уже за 7 месяцев. Это показывает, как быстро технология приходит в «негодность» за счет срока своей работы.

Существует специальная RSA-лаборатория, рекомендующая 1024 бита. Но если потребуется защитить важную информацию, то длина ключей лучше всего увеличить в 2 раза. Если же информация совершенно не ценна, то хватит 768-битного ключа.

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

Что такое самоподписанный сертификат SSL?

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

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

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

Создание самоподписанного SSL-сертификата

Чтобы создать новый самоподписанный сертификат SSL, используйте команду:

Давайте разберем команду и разберемся, что означает каждая опция:

• — Создает новый запрос сертификата и 4096-битный ключ RSA. Значение по умолчанию составляет 2048 бит.
• — Создает сертификат X.509.
• — Используйте 265-битный SHA (алгоритм безопасного хэширования).
• — Количество дней для сертификации сертификата. 3650 — это 10 лет. Вы можете использовать любое положительное целое число.
• — Создает ключ без ключевой фразы.
• — Указывает имя файла, в который будет записан вновь созданный сертификат. Вы можете указать любое имя файла.
• — Задает имя файла, в который будет записан вновь созданный закрытый ключ. Вы можете указать любое имя файла.

Для получения дополнительной информации о параметрах команды посетите страницу документации OpenSSL req.

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

Введите запрашиваемую информацию и нажмите Enter.

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

Это оно! Вы создали новый самозаверяющий сертификат SSL.

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

Создание самоподписанного SSL-сертификата без запроса

Если вы хотите сгенерировать самозаверяющий SSL-сертификат без запроса какого-либо вопроса, используйте параметр и укажите всю информацию о субъекте:

• — Название страны. Двухбуквенное сокращение ISO.
• — Название штата или провинции.
• — Название населенного пункта. Название города, в котором вы находитесь.
• — Полное название вашей организации.
• — Организационная единица.
• — Полное доменное имя.

Подпись сертификатов OpenSSL

Допустим, у вас есть приватный ключ и запрос на подпись, фактически, открытый ключ. Теперь вам нужно его подписать чтобы получить сертификат, который можно использовать. Тут есть несколько вариантов. Можно отправить csr файл на подпись какому-либо центру сертификации, например, LetsEncrypt. Можно подписать сертификат тем же ключом, с помощью которого он был создан, и третий вариант — создать свой центр сертификации.

Первый способ я рассматривать не буду. Здесь все просто. Либо используете утилиту сервиса, либо заполняете веб форму и получаете готовый сертификат. Второй вариант гораздо интереснее. Мы подпишем наш сертификат сами, ключом, на основе которого он был создан:

С помощью параметра -days мы указываем что сертификат будет действительным в течение 365 дней, то есть в течение года. Вы можете объединить все в одну команду и сразу создать закрытый ключ, csr и подписанный сертификат:

Или создаем самоподписанный сертификат openssl из существующего закрытого ключа без csr:

Опция -new говорит, что нужно запросить информацию о csr у пользователя. Чтобы браузер доверял ключу нужно этот же сертификат импортировать в список доверенных. А теперь рассмотрим третий способ выполнить создание сертификата OpenSSL — подписать его с помощью собственного CA, центра сертификации.

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

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

Дальше нужно создать самоподписанный сертификат openssl для нашего CA:

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

Готово, теперь наш сертификат подписан. Но теперь, чтобы браузеры ему доверяли нужно добавить сертификат CA в список доверенных браузера.

Влияние атак квантовых вычислений на силу ключа

Два наиболее известных квантовых вычислений атаки основаны на алгоритме Шора и алгоритма Гровера . Из этих двух Shor’s представляет больший риск для существующих систем безопасности.

Многие предполагают, что производные от алгоритма Шора эффективны против всех распространенных алгоритмов с открытым ключом, включая RSA , алгоритм Диффи-Хеллмана и криптографию на основе эллиптических кривых . По словам профессора Жиля Брассара, эксперта в области квантовых вычислений: «Время, необходимое для разложения целого числа RSA на множители, совпадает с порядком времени, необходимого для использования того же целого числа в качестве модуля для одного шифрования RSA. Другими словами, это не требует больше времени. пора взломать RSA на квантовом компьютере (с точностью до мультипликативной константы), чем законно использовать его на классическом компьютере ». По общему мнению, эти алгоритмы с открытым ключом небезопасны при любом размере ключа, если станут доступны достаточно большие квантовые компьютеры, способные выполнять алгоритм Шора. Последствия этой атаки заключаются в том, что все данные, зашифрованные с использованием современных систем безопасности, основанных на стандартах, таких как вездесущий SSL, используемый для защиты электронной коммерции и интернет-банкинга, и SSH, используемый для защиты доступа к чувствительным компьютерным системам, находятся под угрозой. Зашифрованные данные, защищенные с помощью алгоритмов с открытым ключом, могут быть заархивированы и впоследствии могут быть повреждены.

Широко распространено мнение, что распространенные симметричные шифры (такие как AES или Twofish ) и хэш-функции, устойчивые к коллизиям (такие как SHA ), обеспечивают большую защиту от известных атак квантовых вычислений. Считается, что они наиболее уязвимы для алгоритма Гровера . Беннет, Бернштейн, Брассард и Вазирани доказали в 1996 году, что поиск ключа методом перебора на квантовом компьютере не может быть быстрее, чем примерно 2 n / 2 вызовов базового криптографического алгоритма, по сравнению с примерно 2 n в классическом случае. Таким образом, при наличии больших квантовых компьютеров n- битный ключ может обеспечить как минимум n / 2 бит безопасности. Квантовая грубая сила легко подавляется удвоением длины ключа, что требует небольших дополнительных вычислительных затрат при обычном использовании. Это означает, что для достижения 128-битного рейтинга безопасности против квантового компьютера требуется как минимум 256-битный симметричный ключ. Как упоминалось выше, в 2015 году АНБ объявило, что планирует перейти на квантово-устойчивые алгоритмы.

По данным АНБ:

По состоянию на 2016 год набор алгоритмов национальной коммерческой безопасности АНБ включает:

Алгоритм	использование
RSA 3072-бит или больше	Создание ключа, электронная подпись
Diffie-Hellman (DH) 3072-бит или больше	Ключевое учреждение
ECDH с NIST P-384	Ключевое учреждение
ECDSA с NIST P-384	Цифровой подписи
SHA-384	Честность
AES-256	Конфиденциальность

4 Заключение

Переход от 80-битного уровня безопасности к одному из более высоких уровней безопасности — это хорошая идея. При этом нет причин для беспокойства в использовании 1024-битного RSA до 2014 года. Например, нет оснований полагать, что сертификаты, основанные на 1024-битном RSA должны быть отозваны ранее 2014 года, когда они сами истекут по сроку давности. Аналогично, нет никаких причин беспокоиться по поводу продолжения использования 160-бит ECC над полями простых чисел в течении следующего десятилетия.

Примечание переводчика: глава «Заключение» сокращена. В главе «Благодарности» упоминается, что работа была написана на гранты швейцарского национального научного фонда и Европейской комиссии по программе ECRYPT II. Список литературы, математические приложения, описание процессорной логики в различных архитектурах и подробное изложение используемых алгоритмов также не были включены в перевод.

См. также: «Длина ключа и его полный перебор», «Пределы роста».