Теория и практика OpenSSL::Журнал СА 1.2003
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
20.12.2019г.
Просмотров: 4900
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 6152
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 7390
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 7735
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 6786
Комментарии: 0
Django 2 в примерах

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Теория и практика OpenSSL

Архив номеров / 2003 / Выпуск №1 (2) / Теория и практика OpenSSL

Рубрика: Администрирование /  Документация

ВСЕВОЛОД СТАХОВ

Теория и практика OpenSSL

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

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

Что такое шифрование? Это запись информации в особом виде, исключающем её прочтение лицами, не знающими шифра. В компьютерном мире защита данных актуальна, как нигде. Обычно шифрованием называют обработку данных при помощи некой функции f(x), где x – обрабатываемые данные. Алгоритм шифрования должен быть таким, что даже само знание алгоритма злоумышленником не должно помочь ему открыть ключ шифрования, то есть алгоритм должен основываться на трудоёмкости подбора ключа, а не на неизвестности алгоритма. Алгоритмы шифрования бывают одно и двунаправленными; однонаправленные алгоритмы чаще всего представляют собой так называемые хеши: численное представление некоего текста. Абсолютно очевидно, что даже зная хеш, невозможно вычислить исходный текст (бывает, что для разных текстов хеш совпадает, что тоже естественно, так как множество вариантов текстов бесконечно, а чисел, используемых в алгоритмах – конечно). Для чего же такое нужно? Применение есть замечательное: если одной и той же хеш-функцией обработать одинаковые строки, то результат будет идентичен! Это свойство можно использовать при проверке пароля: строка, введённая пользователем, хешируется и сравнивается с хешем пароля. При этом из хеша пароля восстановить сам пароль нельзя, можно только применять данную хеш-функцию к разным строкам, ища совпадения, т.е. методом прямого перебора. Вот почему советуют выбирать длинные и сложные пароли для важных целей.

Хеш-функций существует огромное множество и есть некоторые стандартные ряды хеш-функций, наибольшее распространение получили ряды MD и SHA. К примеру, стандартная функция Unix crypt вычисляет значение хеш-функции от строки. Один из параметров, передаваемых этой функции, значится как salt, состоит из символов $1$ и строки из 8 символов и определяет выбор хеш-функции из ряда MD5, а возвращаемое значение содержит одиннадцать первых символов salt, чтобы знать в будущем для проверки, какую функцию применять. Если два первых символа salt – произвольная двухсимвольная строка, то используется обычный алгоритм DES (56 бит), а salt определяет выбор алгоритма подмешивания. В настоящее время 56 бит обычно недостаточно, для нахождения ключа длиной 56 бит необходимо перебрать «всего» 72057594037927936 (256) ключей. Для кластера компьютеров эта задача решается в считанные часы, поэтому сейчас во всех современных *nix используется алгоритм MD5, который позволяет генерировать отпечатки (хеши) паролей длиной до 128 бит, для подбора которого потребуются в худшем случае миллиарды лет!

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

К примеру, вы хотите пройти аутентификацию на удалённой машине и посылаете ей свой пароль, конечно же, не сам пароль, а его хеш. Но, к сожалению, где-то на пути встретился хаб, который дал возможность послушать ваши пакеты снифером. Этим, естественно, воспользовался злой дядька, подключённый к этому хабу. Он смог беспрепятственно взять ваш хеш пароля, взломать его (если повезёт) или просто посылать этот же хеш серверу. Таким образом, под вашим логином входят два человека. Не думаю, что кого-то развеселит эта ситуация (разве что злого дядьку, если его не засекут). Или ещё пример полной беззащитности: электронная почта не защищается никак (по крайней мере, по стандартной схеме) и всякий может её прочитать или изменить. Нет-нет, не надо бежать в хозяйственный магазин за мыльцем и верёвочкой – спасение есть. Это асимметрическое шифрование. Идея такова: вначале от генератора случайных чисел формируется определённая строка – секретный ключ, который может использоваться для расшифровки данных, зашифрованных публичным ключом. Публичный ключ вычисляется на основании секретного ключа. Таким образом мы получили пару ключей для шифрования (публичный ключ) и расшифровывания (секретный ключ). Затем на удалённой машине также создаётся подобная пара ключей (скорее всего она будет иной, так как довольно сложно, чтобы на разных машинах генератор случайных чисел генерировал одну и ту же последовательность). Итак, у нас есть две пары ключей, мы должны обменяться публичными ключами. После этого вы можете, используя публичный ключ удалённой машины, зашифровывать данные, которые могут быть расшифрованы ею с помощью имеющегося только у неё секретного ключа. Так как удалённая машина имеет и ваш публичный ключ, то подобная операция может работать наоборот (т.е. передача данных на вашу машину). Да, вроде бы всё хорошо: информация, передаваемая между машинами, может быть расшифрована только ими, но есть одно «но». Представьте ситуацию подмены публичных ключей при доставке: тогда правильный ключ будет считаться неправильным, а подменённый ключ – правильным. Обычным методом защиты публичного ключа асимметрического шифрования является его сертификация. Для понятия сертификации сразу же необходимо объяснить, что такое электронная цифровая подпись. ЭЦП – это хеш сообщения с данными об отправителе, подписанный секретным ключом последнего. На основании ЭЦП можно определить достоверность и неизменность сообщения при условии, что имеется публичный ключ. Публичный ключ, анализируя ЭЦП, даёт один из ответов: достоверен, недостоверен (был изменён). А так как найти такое значение хеша, чтобы оно совпадало для двух различных сообщений (т.е. h(M)=h(M’)) очень сложно, сопоставимо с прямым перебором, то практически нет способа подменить сообщение, подписанное ЭЦП. При пересылке публичного ключа его подмена обычно исключается электронной подписью, гарантирующей неизменность данных. Обычно публичный ключ подписывается либо секретным ключом данной пары, либо одним из доверенных ключей сторонних организаций. То есть в любом случае к ключу ЭЦП должно быть доверие. Такой механизм полностью исключает подмену публичного ключа, так как в противном случае подпись будет недостоверна и программа установления безопасной связи просто не примет данного ключа, автоматически считая его неверным.

Есть ещё возможность исключить перехват публичного ключа – подтверждение получения ключа от другой машины и обмен идентификационными сообщениями. Такой метод применён, например, в механизме беспарольной аутентификации SSH. Вы обмениваетесь ключами с сервером и звоните владельцу удалённой машины (особенно это актуально при аутентификации клиента на сервере путём подтверждения валидности ключа), подтверждая и проверяя передачу ключа. При таких методах защиты полностью исключен перехват конфиденциальных данных, если, конечно, не вывесить свой секретный ключ на доску почёта в раздел «Достижения в безопасности за последний квартал». А если серьёзно, то потеря секретного ключа позволяет любому расшифровывать всё, что зашифровано вами или для вас, то есть происходит полная потеря безопасности. Поэтому во многих системах аутентификации секретные ключи дополнительно шифруются неким паролем. Без пароля секретный ключ представляет собой меньше ценности, так как ломать пароль можно только прямым перебором. Но всё же лучше держать секретные ключи при себе.

Ещё многих интересует, что означает стойкость ключа. Это просто длина ключа в битах. Чем она больше, тем больше степень сложности подбора секретного ключа перебором. Но одновременно с этим увеличивается время работы алгоритмов и увеличивается объем сообщений за счёт неиспользуемых элементов ключа. Поэтому здесь лучше не бросаться в крайности, стойкость ключа длиной в 1024 бит вроде бы является достаточной (в настоящее время), хотя при пересылке почтовых сообщений используют ключи длиной до 2048 бит (OpenPGP). Для ключей симметрического шифрования достаточной является длина 128 бит. Ещё критичным фактором является работа генератора случайных чисел. Если злоумышленнику удалось найти некую закономерность в генераторе случайных чисел, то ему ничего не стоит создать любой ключ (а зачастую и «случайные» пароли). Поэтому сообщения о громких взломах различных ключей чаще всего вызваны тем, что злоумышленник нашёл баг в генераторе случайных чисел.

Некоторых интересует также, что означают загадочные надписи RSA и DSA. Это сокращённые названия алгоритмов асимметрического шифрования. Различаются они математической основой работы, которая определяет степень защищённости и скорость работы в разных режимах (во многих системах существует также ограничение на длину DSA ключей в 1024 бита, ключи RSA могут быть любой длины, но обычно используются ключи 1024 – 4096 бит). Среди алгоритмов симметрического шифрования наиболее распространены следующие:

  • DES (56 бит);
  • 3DES (168 бит);
  • RC* (40 – 128 бит);
  • Blowfish (128 бит);
  • IDEA (128 бит).

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

При использовании клиентов, работающих на безопасных каналах связи (SSL – secure socket layer), часто можно видеть запрос на подтверждение публичного ключа для связи или сертификата (подписанного публичного ключа, как было описано ранее). Как я уже говорил, публичный ключ могут подменить, но если вы доверяете своим каналам связи и не думаете, что кто-то охотится персонально за вашими данными, то можно доверять публичному ключу удалённого сервера, так как подмена ключа – занятие довольно трудоёмкое, а если у вас есть некие подозрения на этот счёт, то лучше не доверять ключу, не получив подтверждения от нужного лица или организации (не вздумайте использовать электронную почту: уж если смогли подделать ключ, то подменить письмо не составляет труда). Генерация ключей клиента происходит на лету и они автоматически удаляются после окончания сеанса связи, публичный ключ удалённого сервера помещается в специальное хранилище, что избавляет вас от риска пересылки публичного ключа. Основные атаки на системы асимметрического шифрования связаны с тем, что злоумышленник может угадать содержимое части зашифрованных данных (например, письма часто начинаются со слов «Здравствуйте, »), и это знание облегчает подбор секретного ключа. Ещё очень опасна атака на подмену ключей (man-in-the-middle), когда злоумышленник перехватывает публичные ключи двух людей, затем генерирует две пары ключей и направляет свои публичные ключи обеим сторонам. Теперь первый человек посылает злоумышленнику своё письмо, которое тот расшифровывает своим ключом, читает, зашифровывает публичным ключом второго человека и отправляет ему послание. Таким образом, у людей создается иллюзия защищённой переписки, но читает их сообщения и третий (который, как известно, лишний). Выходом из такой ситуации является сертификация публичных ключей. Существует два способа сертификации ключей:

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

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

Безопасность сервера необходима лишь в случае удаленной беспарольной аутентификации, тогда администратор удалённой системы помещает ваш ключ в список известных ключей системы. Примечание для администраторов: если вы не хотите, чтобы все могли использовать данный ключ, объясните пользователю опасность доступа посторонних лиц к его секретному ключу и убедите его зашифровать секретный ключ паролем, который, кстати, можно удобно хранить в памяти и не вводить лишний раз, но об этом я расскажу в статье об SSH. И ещё: не забывайте убедиться в том, что ключ пришёл от того, кого предполагалось, для этого лучше попросить пользователя принести ключик на дискетке, а потом её дезинтегрировать или оставить в эпицентре ядерного взрыва (жаль этого нельзя проделать с некоторыми «пользователями», хотя почему нельзя? Мария Францевна, подойдите-ка на минутку...)

И наконец, скажу ещё вот что: асимметрическое шифрование используется для подписи и зашифровывания почтовых сообщений, удалённой аутентификации и ЭЦП в любых её применениях. Но для передачи большого количества данных через сеть использовать асимметрическое шифрование очень печально – всё загнется окончательно и бесповоротно: уж больно много времени надо для использования подобных алгоритмов. Поэтому при передаче данных по сети используют симметрическое шифрование (3DES, IDEA, Blowfish). Но ключ симметрического шифрования очень опасно передавать в открытом виде (ведь он используется для шифрования и дешифрования), и вначале устанавливается связь асимметрическим шифрованием, как было описано выше. После установления связи клиент генерирует ключ симметрического шифрования и шифрует его публичным ключом сервера, затем отправляет его собственно серверу (также выполняется подписывание симметрического ключа для удостоверения в его неизменности). Сервер расшифровывает своим секретным ключом ключ симметрического шифрования и использует его для общения с клиентом. Красота! Но есть ещё один способ – алгоритм Дифлемана-Хельмана, позволяющий использовать одни и те же ключи как для симметрического, так и для асимметрического шифрования. Он заключается в нехитрых математических законах степенной функции (я не буду на этом заострять внимание, так как вряд ли это пригодится на практике). Оказывается, имея пару – публичный ключ A и секретный ключ B, можно вычислить ключ симметрического шифрования С, который также получается при наличии пары ключей секретный А и публичный B. Говоря проще, ключ С однозначно могут вычислить обе машины, обменявшиеся публичными ключами. Этот ключ можно далее использовать для шифрования/дешифрования данных по стандартному алгоритму симметрического ключа. Такой способ достаточно безопасный, но он пока ещё не получил достаточного распространения и поэтому сейчас чаще используется первый способ. Любопытные тут же поинтересуются: почему, когда я говорил о симметрическом шифровании, я сказал, что 128-и битный ключ теоретически несокрушим, а говоря об асимметрическом шифровании, сказал, что ключ длиной 1024 бит считается пока ещё более-менее безопасным. Тут дело вот в чём: при асимметрическом шифровании выбираются 2 больших простых числа и на их основе создаются секретный и публичный ключи. Не вдаваясь в математику (для математической стороны алгоритмов шифрования можете зайти на лучший алгоритмический ресурс в рунете http://algolist.manual.ru), скажу только одно: для вычисления секретного ключа на основании публичного необходимо выполнить задачу разложения на множители, которая пропорциональна логарифму по модулю большого целого числа (это реализовать намного проще, чем прямой перебор).

Ну вот, с теорией покончено, можно приступить к практике.

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

Так как OpenSSL поддерживает очень много различных стандартов сертификации, шифрования, хеширования, то использование данной команды достаточно сложно. Внутри OpenSSL существуют отдельные компоненты, отвечающие за то или иное действие. Для получения списка доступных компонентов можно вызвать openssl с параметрами list-standart-commands. Можно также получить список доступных алгоритмов хеширования (list-message-digest-commands) и алгоритмов шифрования (list-cipher-commands). Итак, с помощью команд OpenSSL можно делать следующее:

  • Создавать и управлять ключами RSA и DSA – команды rsa, dsa, dsaparam;
  • Создавать сертификаты формата x509, запросы на сертификацию, восстановление – команды x509, req, verify, ca, crl, pks12, pks7;
  • Зашифровывать данные с помощью симметрического или асимметрического шифрования – команды enc, rsautl;
  • Высчитывать хеши различных типов – команда dgst;
  • Работать с S/MIME – команда s/mime;

Проверять работы серверов и клиентов ssl – команды s_client, s_server.

Cуществует также несколько вспомогательных утилит ssl:

  • openssl speed [список_алгоритмов_хеширования_или шифрования]: тестирование скорости различных алгоритмов, если запускать без параметров, то тестируются все алгоритмы; алгоритмы внутри списка разделяются пробелом, например:

 openssl speed md5 rsa idea blowfish des 3des sha1

В конце выводится общая скорость работы различных алгоритмов (в 1000-х байт в секунду), для обработки различной длины блоков. Вот результат работы тестов скорости на моём домашнем компе (Celeron 366), на других компах значения будут другими:

Таблица 1

Алгоритм

8 байт

64 байт

256 байт

1024 байта

8192 байт

md2

291.38k

817.15k

1109.67k

1218.56k

1256.11k

mdc2

868.57k

911.02k

914.01k

915.11k

917.50k

md4

4417.91k

24808.28k

51404.97k

70189.40k

78168.06k

md5

3905.61k

21142.91k

41515.69k

55489.54k

59091.63k

hmac(md5)

1536.42k

10381.81k

27585.13k

46119.35k

57671.68k

sha1

2458.59k

11965.97k

21560.58k

26889.22k

29143.66k

rmd160

2032.99k

9523.48k

16568.15k

20547.81k

22220.11k

rc4

28775.08k

39239.02k

41210.52k

41862.98k

41454.25k

des cbc

7586.90k

8411.44k

8580.28k

8627.29k

8612.52k

des ede3

2866.13k

3031.96k

3050.92k

3074.74k

3058.35k

idea cbc

4948.09k

5743.19k

5760.09k

5744.67k

5723.48k

rc2 cbc

2982.04k

3220.39k

3256.32k

3263.49k

3268.61k

rc5-32/12 cbc

19108.39k

24151.19k

24906.75k

25154.90k

25212.25k

blowfish cbc

11018.91k

12881.27k

12925.01k

12972.37k

13047.13k

cast cbc

10943.48k

12674.30k

12877.74k

12994.56k

13011.63k

Таблица 2. Проверка алгоритмов асимметрического шифрования

 

Подписывание

Проверка

За секунду подписывает

За секунду проверяет

rsa  512 bits

0.0036s

0.0003s

281.4

3221.7

rsa 1024 bits

0.0184s

0.0009s

54.3

1072.9

rsa 2048 bits

0.1105s

0.0032s

9.0

315.6

rsa 4096 bits

0.7414s

0.0112s

1.3

89.4

dsa  512 bits

0.0032s

0.0038s

311.3

261.3

dsa 1024 bits

0.0093s

0.0116s

107.5

86.4

dsa 2048 bits

0.0309s

0.0377s

32.4

26.5

  • openssl rand [-out file] [-rand file] num: генерация num рандомных байт:

# openssl rand 5

Wеб~

#

  • openssl ciphers [-ssl2] [-ssl3] [-tls1] NAME: вывод доступных алгоритмов для обеспечения уровня безопасности NAME, где NAME – это символическое название группы алгоритмов. Обычно используются значения:
    • LOW – алгоритмы низкого уровня безопасности (меньше 128 бит);
    • MEDIUM – алгоритмы среднего уровня стойкости (128 бит);
    • HIGH – алгоритмы высокой стойкости (больше 128 бит);
    • ALL – все алгоритмы;
    • NULL – алгоритмы без шифрования.

Обычно в настоящее время используются алгоритмы групп MEDIUM и HIGH, которые ещё долго не смогут быть взломаны прямым перебором. Можно также вывести список алгоритмов из нескольких групп, разделив их «:» (например, MEDIUM:HIGH).

Теперь я бы хотел рассказать об основных утилитах openssl. Для начала я расскажу о методах генерации ключей, затем о командах шифрования и, наконец, о сертификатах, s/mime, клиент/серверных тестах. Итак, пару слов о генерации ключей. Для создания rsa ключей используется команда genrsa:

openssl genrsa [-out file] [-des | -des3 | -idea] [-rand file] [bits]

Команда genrsa создаёт секретный ключ длиной bits в формате PEM, шифрует его одним из алгоритмов des (56 бит), des3 (3-й des 168 бит) или idea (128 бит). При выборе алгоритма шифрования будет запрошен пароль для шифрования создаваемого секретного ключа (если алгоритм не указан, то секретный ключ не шифруется, чего делать ни в коем случае нельзя). Опция -out говорит программе, что вывод нужно осуществлять не в stdout, а в файл file (опция -out присутствует во множестве других компонентов openssl и используется аналогичным образом для указания выходного файла). Опция -rand указывает на файл/файлы (разделённые «:»), из которых будут считываться данные для установки seed генератора случайных чисел. В качестве таких файлов сразу же приходит на ум использовать что-то вроде /dev/random или /dev/urandom, но у меня с этим возникли проблемы – всё вешалось наглухо, поэтому я рекомендую в этом случае использовать какие-нибудь сложно угадываемые файлы, вроде /var/log/messages или /boot/vmlinuz, думаю, что угадать содержимое этих файлов не намного проще чем содержимое /dev/random, но работает этот фокус в любом *nixe (опция -rand также присутствует во всех компонентах генерации и управления ключами и сертификатами). Использовать /dev/random и /dev/urandom, конечно, можно, но я для этого скопировал из /dev/random 32 768 байт в файл .rnd таким образом:

dd if=/dev/[u]random of=.rnd count=64

Кроме этого, можно указывать в качестве -rand файла EGD сокет, который обеспечивает генерацию определённого количества случайных байт, EGD доступен на узле http://www.lothar.com/tech/crypto. Установка генератора случайных чисел производится на основании хеша -rand файла, поэтому можно указывать файлы различной длины, так как хеш все равно имеет фиксированное число бит. Пример генерации 4096-битового секретного ключа RSA:

# openssl genrsa -out /etc/openssl/key.pem -des3 -rand /var/log/messages 4096 

Generating RSA private key

.....++*...++++++++*

Enter PEM passphrase:

Verify PEM passphrase:

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

openssl rsa -in filename [-out file] [-des | -des3 |-idea] [-check] [-pubout]

Утилита openssl rsa способна изменять пароль и алгоритм шифрования секретного ключа, будучи вызвана с параметром -in и -out. Если применить параметр -pubout, то в указанный файл -out будет записан публичный ключ, вычисленный на основе -in секретного. Например, создание публичного ключа на основании секретного:

openssl rsa -in /etc/openssl/key.pem -out /etc/openssl/pubkey.pem -pubout

Изменение пароля и алгоритма шифрования секретного ключа с des3 на idea:

openssl rsa -in /etc/openssl/key.pem -out /etc/openssl/key1.pem -idea

Для создания ключей DSA используется утилита openssl gendsa, аналогичная genrsa, но есть два отличия: во-первых, для ключей DSA нельзя указывать длину в битах и, во-вторых, ключи DSA могут генерироваться согласно некоторым параметрам, записанным в файл paramfile утилитой openssl dsaparam, имеющей следующий формат:

openssl dsaparam [-rand file{s}] [-C] [-genkey] [-out file]  numbits

где numbits – длина желаемого ключа, -С заставляет dsaparam вывести на stdout код на СИ для программной генерации DSA на основе необходимых параметров, а опция -genkey говорит, что в выходной файл, наряду с параметрами, дополнительно записывается созданный секретный ключ DSA, но нельзя его сразу же зашифровать, поэтому удобнее воспользоваться утилитой openssl gendsa, которая имеет схожий синтаксис с командой genrsa, но вместо числа бит указывается файл параметров, созданный dsaparam:

# openssl gendsa -out /etc/openssl/dsakey.pem -rand /boot/vmlinuz -idea paramfile Enter PEM passphrase: Verify PEM passphrase:

Для управления ключами dsa используется программа openssl dsa, которая абсолютно аналогична (в параметрах) утилите openssl rsa. Поэтому я просто приведу пример генерации публичного ключа DSA:

# openssl dsa -in /etc/openssl/dsakey.pem -out /etc/openssl/pubdsakey.pem -pubout

Теперь настало время рассказать о компонентах openssl, выполняющих шифрование и хеширование данных. Для выполнения симметрического шифрования используется утилита openssl enc -cipher или её сокращённая запись openssl cipher, где cipher – это одно из символических имён симметрических шифров. Наиболее популярными являются следующие:

  • base-64 (преобразование в текстовый вид);
  • bf (blowfish – 128 бит);
  • des (56 бит);
  • des3 (168 бит);
  • rc4 (128 бит);
  • rc5 (128 бит);
  • rc2 и idea (128 бит).

Для указания входного и выходного файлов используются опции -in и -out соответственно. Пароль для шифрования вводится с клавиатуры (можно указать в командной строке параметром -k, но это очень плохо по соображениям безопасности, так как большинство шелов умеют сохранять историю командной строки, на мой взгляд, намного лучше ввести пароль непосредственно перед шифрованием). Учтите, что пароль не спрашивается при обработке файла base64, так как шифрования не происходит. Для расшифровки зашифрованных данных примените openssl cipher с опцией -d (алгоритм шифрования и дешифрования должен совпадать!), а для одновременной обработки данных base64 можно воспользоваться опцией -a. Шифрование по умолчанию происходит с подмешиванием (подсолением), для выбора алгоритма подмешивания используется случайная соль (salt), поэтому, если вы шифруете один и тот же файл в разное время одним и тем же алгоритмом и паролем, то результаты скорее всего будут разными (это затрудняет атаку по словарю). Также по умолчанию используется cbc режим алгоритмов, когда ключ меняется в течение всего сеанса работы согласно передаваемым данным. Приведу несколько примеров:

  • зашифруем файл, используя алгоритм des3:

# openssl des3 -in file -out file.des3

  • расшифруем полученный файл:

# openssl des3 -d -in file.des3 -out file

  • зашифруем файл, используя алгоритм blowfish(bf), и закодируем base64:

# openssl bf -a -in file -out file.bf64

  • теперь расшифруем его и обработаем сразу же base64:

# openssl bf -a -d -in file.bf64 -out file

Для вычисления хешей используется команда openssl dgst -hashalg или краткая форма openssl hashalg (первая команда может также выполнять манипуляции с ЭЦП, но об этом далее). Обычное использование данной команды таково openssl hashalg [-c] file[s]. Вычисляется хеш сообщения фиксированной длины в виде одной строки или, если указана опция -c, строки, разделённой на пары HEX чисел двоеточием.

Среди алгоритмов хеширования могут применяться следующие:

  • md2 (128 бит);
  • md4 (128 бит);
  • md5 (128 бит);
  • mdc2 (128 бит);
  • sha (160 бит);
  • sha1 (160 бит);
  • ripemd160 (160 бит).

Опять же приведу пару примеров:

  • вычислим md5 хеш файла:

# openssl md5 -c file MD5(file)= 81:fd:20:ff:db:06:d5:2d:c3:55:b5:7d:3f:37:ac:94

  • а теперь SHA1 хеш этого же файла:

# openssl sha1 file SHA1(file)= 13f2b3abd8a7add2f3025d89593a0327a8eb83af

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

openssl dgst -sign private_key -out signature -hashalg  file[s]

Подписывание file с помощью секретного ключа private_key, используя алгоритм хеширования hasalg (обычно применяются sha1 или md5).

openssl dgst -signature signature -verify public_key file[s]

Проверка подписи в file, используя публичный ключ public_key и ЭЦП signature. Данная программа выводит «Verification OK» при правильной подписи или «Verification Failure» в любом другом случае. Учтите, что ЭЦП в таком случае хранится отдельно от файла, который ею подписан.

Для шифрации и дешифрации RSA алгоритмом используется программа rsautl. Данная утилита имеет также возможность подписывать и проверять подпись сообщений (однако работать всё равно приходится с хешем сообщения, так как подписывать можно только небольшой объём данных, поэтому лучше применять openssl dgst). Для шифрации/дешифрации используется следующий синтаксис:

openssl rsautl -in file -out file.cr -keyin pubkey.pem -pubin -encrypt

Шифрация file с использованием публичного ключа pubkey.pem.

openssl rsautl -in file.cr -out file -keyin secretkey.pem -decrypt

Дешифрация file.cr с использованием секретного ключа secretkey.pem.

Теперь настало время рассказать об одном из главных применений openssl – управление сертификатами. Openssl имеет возможность генерировать сертификаты, управлять ЭЦП и шифрованием с помощью сертификатов. Однако применение утилит управления сертификатами – достаточно сложная задача. Поэтому для начала я дам общие представления о сертификатах. Сертификат содержит публичный ключ, подписанный одним из корневых доверенных центров сертификации (или комплементарным секретным ключом), данные об организации, выдавшей сертификат, и в некоторых случаях зашифрованный секретный ключ, а также отпечаток (хеш) публичного ключа. Сертификаты имеют время действия, по окончании которого они автоматически считаются недействительными, иерархия сертификатов обычно строится на основании сети доверия (бывают довольно длинные цепочки сертификатов, ведущие к доверенному ключу из root CA). Таким образом, сертификат – это полный комплекс системы асимметрического шифрования, предоставляющий гораздо больше возможностей, чем сами по себе ключи (а также являющийся более защищённой системой). Основным привлекательным моментом сертификата является возможность записи в него информации об организации, этот ключ выдавшей. Таким образом, явно напрашивается применение собственной системы сертификации в данной организации. Можно, например, выдавать сотрудникам их персональные сертификаты, подписанные сертификатом организации (его можно сгенерировать самому или получить от сторонней компании). Причём эти сертификаты впоследствии можно использовать для удостоверения личности сотрудника, например, при почтовой переписке или аутентификации на http-сервере (apache+ssl). Единственное условие, которое должно выполняться, – это наличие на машине клиента сертификата организации в списке корневых доверенных ключей. Общее содержание сертификатов определено стандартом x509, в то время как форматы записей сертификатов могут внести некоторую путаницу. Openssl по умолчанию использует формат PKCS#10, Microsoft использует по умолчанию формат PKCS#12 (в руководстве по openssl этот формат охарактеризован как один большой баг), формат PKCS#7 используется для запросов на сертификацию к CA (центр сертификации) и не может содержать секретного ключа, также для этой цели может использоваться DER-закодированный сертификат (DER-кодирование подобно кодированию base64, но имеет специальное назначение для использования в криптографических системах) также без секретного ключа. Учтите, что при использовании DER-формата убираются маркеры начала и конца сертификата, а его содержимое кодируется base64, поэтому в файле DER можно хранить только один сертификат, с другой стороны DER-сертификаты поддерживаются M$ (стандартное расширение .cer), поэтому иногда бывает нужно преобразовать сертификаты из одного формата в другой (я здесь имею в виду PEM или DER):

PEM—>DER openssl x509 -inform PEM -in cert.pem -outform DER -out cert.cer

DER—>PEM openssl x509 -inform DER -in cert.cer -outform PEM -out cert.pem

Таким же образом можно конвертировать и ключи асимметрического шифрования (используя утилиты rsa или dsa).

Думаю, что не сильно запутал вас всеми этими стандартами. Если объяснять на пальцах, то всё выглядит следующим образом: клиент создаёт сертификат и отправляет свой публичный сертификат (PKCS#7) в центр сертификации. В центре сертификации обрабатывается запрос клиента (запрос на сертификацию), и сертификат клиента подписывается секретным ключом центра сертификации. Клиент, имея публичный ключ центра сертификации, проверяет подлинность подписи и может далее использовать свой сертификат. Для организации можно предложить следующее решение: на сервере создаётся сертификат организации; генерируется запрос на сертификацию и отправляется к некоему доверенному центру сертификации (который будет известен всем клиентам и персоналу данной организации); получается сертификат организации, который можно использовать при создании сертификатов клиентов. Последние создаются так: клиент посылает запрос на выдачу сертификата; сервер создаёт сертификат клиента и подписывает его сертификатом организации; клиент получает сертификат клиента и сертификат организации; после проверки достоверности ключа организации (предполагается, что клиент доверяет CA, которым был подписан сертификат организации) проверяется достоверность сертификата клиента. После такой операции клиент будет точно уверен, что получил сертификат от данной организации и может его использовать для работы с ней. По такой схеме построены все центры выдачи сертификатов (правда зачастую сертификат организации бывает подписан самим собой, что требует от клиента добавить сертификат организации к доверенным, а в первой схеме сертификат организации принадлежит к группе промежуточных центров сертификации, и этот случай предпочтительнее с точки зрения безопасности и удобства клиента, но требует больше работы от администратора). Да, хорошенькое объяснение на пальцах! Но что тут поделать: сертификаты – это довольно запутанная вещь. Сейчас я объясню, как создавать сертификаты с помощью openssl и приведу пример только что описанного безобразия...

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

[ req ]

# Секция основных опций

default_bits = 2048

# Число бит

default_keyfile = keyfile.pem

# Имя ключа, используемого для  сертификата

distinguished_name = req_distin-guished_name

# DN организации, выдавшей  сертификат

prompt = no

# Брать параметры из конфига неинтерактивный режим

[ req_distinguished_name ]

# DN организации

C=RU

# Страна

ST=Ivanovskaya

# Область

L=Gadukino

# Город

O=Krutie parni

# Название организации

OU=Sysopka

# Название отделения

CN=Your personal certificate

# Имя для сертификата (персоны, получающей сертификат)

emailAddress=certificate@gaduk.ru

# Мыло организации

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

имя = подсказка

имя_default = значение_по_умолчанию

имя_max = максимум

имя_min = минимум

Пример интерактивного файла конфигурации:

[ req ]

default_bits = 1024

default_keyfile = privkey.pem

distinguished_name = req_distin-guished_name

[ req_distinguished_name ]

countryName = Country Name (2 letter code)

countryName_default = RU

countryName_min = 2

countryName_max = 2

localityName = Locality Name (eg, city)

organizationName = Organization Name(eg, org)

organizationalUnitName = Organizational Unit Name (eg, section)

commonName = Common Name (eg, YOUR name)

commonName_max = 64

 emailAddress = Email Address

emailAddress_max = 40

Спешу обрадовать некоторых ленивых товарищей: если вы намереваетесь создавать просто сертификат сервера (например, для LDAP-сервера), то указывать конфиг необязательно, будет использоваться конфиг по умолчанию /usr/lib/ssl/openssl.cnf, который содержит всё необходимое. Ну а теперь традиционно приведу примеры использования openssl req (я не собираюсь подробно описывать данную команду, так как думаю, что для большинства случаев хватит примеров, а для особых случаев можно почитать man req).

openssl req -new -newkey rsa:2048 -keyout rsa_key.pem -config cfg -out certreq.pem

Создание запроса на сертификацию (-new) на основе создаваемого секретного ключа rsa (-newkey rsa:2048), который записывается в файл -keyout (и шифруется тройным DES). Запрос на сертификацию создаётся на основе конфигурационного файла-config.

openssl req -x509 -new -key private_key.pem -config cfg -out selfcert.pem -days 365

Создание (-new) self-signed сертификата (-x509) для использования в качестве сертификата сервера или сертификата CA. Сертификат создаётся с использованием секретного ключа -key и конфигурационного файла -config. Создаваемый сертификат будет действителен в течение 365 дней (-days), опция -days не применима к запросам на сертификацию.

Для управления сертификатами x509 используется утилита openssl x509. С её помощью можно подписать сертификат или запрос на сертификацию сертификатом CA. Также можно просмотреть содержимое сертификата в читаемой форме (DN, публичный ключ, время действия, отпечаток и т. д.). Приведу примеры вышеописанных действий:

openssl x509 -in cert.pem -noout -text

Просмотреть информацию о сертификате в «нормальной» форме. Вот что примерно будет выведено, также можно использовать дополнительные опции: -fingerprint (необходимо сочетать с одной из опций -sha1, -md5 или -mdc2), -modulus (вывод публичного ключа), -serial, -subject, -issuer (организация, выдавшая сертификат), -email, -startdate, -enddate:

 Certificate:

       Data:

          Version: 3 (0x2)

          Serial Number: 0 (0x0)

          Signature Algorithm: md5WithRSAEncryption

          Issuer: C=RU, ST=region, L=city, O=organization, OU=Sysopka,

CN=CEBKA/Email=CEBKA@smtp.ru

          Validity

             Not Before: Nov  9 08:51:03 2002 GMT

             Not After : Nov  9 08:51:03 2003 GMT

          Subject: C=RU, ST=region, L=city, O=organization, OU=Sysopka,

CN=CEBKA/Email=CEBKA@smtp.ru

          Subject Public Key Info:

             Public Key Algorithm: rsaEncryption

                 RSA Public Key: (1024 bit)

          Modulus (1024 bit):

                          00:c6:6b:3b:8e:f8:33:05:a0:dc:e1:38:8f:6a:68:

                          42:1c:21:33:aa:90:b6:8c:93:14:11:9b:69:94:8a:

                          3a:0e:42:29:b0:45:14:1b:f0:37:2c:f3:05:db:13:

                          06:a9:cd:eb:99:31:51:25:86:c8:69:e0:5e:8d:28:

                          04:8d:1f:08:37:d7:72:39:fe:05:57:61:68:95:bf:

                          5c:ae:13:f2:05:a1:29:c3:bf:3b:32:ca:1a:ff:22:

                          53:f9:32:92:78:fe:44:c3:e1:ca:42:5c:5f:d1:49:

                          da:1c:9f:34:06:04:ee:46:74:8d:11:68:ef:37:e2:

                          74:1e:d9:46:04:b8:7e:d5:c5

                Exponent: 65537 (0x10001)

          Signature Algorithm: md5WithRSAEncryption

          3b:42:85:45:08:95:f3:f1:fc:8a:23:88:58:0e:be:e5:9b:56:

          1e:c1:ff:39:28:4f:84:19:f8:3e:38:ef:98:34:d6:ee:e0:0a:

          de:36:3a:5c:15:88:d7:2a:a4:0a:d5:dc:3e:b2:72:4c:82:57:

          b8:fe:52:f6:e2:06:01:38:eb:00:0b:f2:a9:87:be:65:83:19:

          13:50:ae:6c:f2:0a:07:14:e6:8c:60:cd:c5:a3:d1:e1:ea:da:

          24:c2:6a:06:d5:dc:1c:71:c9:64:fa:9e:c9:ca:97:e2:06:84:

          de:4c:69:b8:9a:af:66:14:8d:46:9a:00:53:13:c9:ab:10:b8:

          09:c2

Подписать запрос на сертификацию (-req) файла -in, используя доверенный CA сертификат -CA и его секретный ключ -CAkey. В конечный сертификат клиента (-out) записываются дополнительные параметры сертификата третьей версии из файла /usr/lib/ssl/openssl.cnf (конфигурационный файл по умолчанию). Но об этом я расскажу после на конкретном примере. Такое поведение x509 позволяет организовать свой центр сертификации, подписывающий запросы клиентов на сертификацию.

openssl x509 -in CAcert.pem -addtrust sslclient -alias «myorganization CA» -out CAtrust.pem

Преобразование сертификата -in в доверенный сертификат для использования в SSL-клиентах (sslserver – использование в качестве сертификата сервера, emailProtection – использование в качестве сертификата S/MIME).

Я ещё раз хотел бы вернуться к проблеме построения CA. Для использования внутри организации можно взять self-signed сертификат, но для использования СА вне организации приходится брать сертификаты, выданные или подписанные сторонней организацией. Во втором случае возникает проблема выбора такой сторонней организации (она легко разрешается для дочерних компаний), которая требует юридического анализа (в разных странах существуют свои законы криптографии и поэтому дать какой-либо конкретный совет я не могу). Если вам довелось работать в российской правительственной компании, то считайте, что вам не повезло – использовать openssl для работы с правительственными организациями нельзя. Наши уважаемые государственные деятели добавили кучу проблем админам, разрешив использовать только алгоритмы ГОСТ (симметрические, асимметрические, хеширования – меня просто выворачивает от самого этого слова ГОСТ), поэтому использовать вам придётся только специальные программы, реализующие эти алгоритмы. Я же приведу здесь пример построения собственного CA с self-signed сертификатом:

  • Генерируем секретный ключ:

openssl genrsa -out CAkey.pem -rand randfile -des3 4096

  • Создаём self-signed сертификат:

openssl req -new -x509 -key CAkey.pem -out CAcert.pem -days 365 -config cfg

Содержимое конфигурационного файла зависит от организации, можно даже воспользоваться утилитой /usr/lib/ssl/misc/CA.pl -newcert, которая создаст ключ и сертификат в одном файле в интерактивном режиме (хотя мне этот вариант не очень понравился, лучше один раз написать нормальный конфиг) – о дополнительных требованиях к конфигурации CA сертификата смотри ниже.

  • Генерируем клиентские сертификаты, например, как приведено ниже:

#!/bin/bash

dd if=/dev/random of=/tmp/.rnd count=64

RAND="/var/log/messages:/boot/vmlinuz:/tmp/.rnd"

REQ="openssl req"

X509="openssl x509"

RSA="openssl rsa"

GENRSA="openssl genrsa"

O="company"

C="RU"

ST="region"

L="city"

PURPOSES="digitalSignature, keyEncipherment"

CERTTYPE="client, email, objsign"

CA="/etc/openssl/CAcert.pem"

CAkey="/etc/openssl/CAkey.pem"

OUTDIR="/etc/openssl/clientcert/"

CN="client"

BITS=2048

DAYS=365 

#Создаём секретный ключ во временной папке БЕЗ шифрования

TMP="/tmp/ssl-$$"

mkdir $TMP

if [ ! -d $OUTDIR ];then

    mkdir $OUTDIR

fi

pushd $TMP > /dev/null

$GENRSA -rand $RAND -out tmp.key $BITS 

# Создаём конфиг для клиента

cat > cfg <

[ req ]

default_bits                   = $BITS

distinguished_name             = req_DN

extensions                     = v3_req

[ req_DN ]

countryName                    = "1. Country Name             (2 letter code)"

countryName_default            = "$C"

countryName_min                = 2

countryName_max                = 2

stateOrProvinceName            = "2. State or Province Name   (full name)    "

stateOrProvinceName_default    = "$ST"

localityName                   = "3. Locality Name            (eg, city)     "

localityName_default           = "$L"

0.organizationName             = "4. Organization Name        (eg, company)  "

0.organizationName_default     = "$O"

organizationalUnitName         = "5. Organizational Unit Name (eg, section)  "

organizationalUnitName_default = "$OU"

commonName                     = "6. Common Name              (eg, CA name)  "

commonName_max                 = 64

commonName_default             = "$CN"

emailAddress                   = "7. Email Address            (eg, name@FQDN)"

emailAddress_max               = 40

emailAddress_default           = ""

[ v3_req ]

basicConstraints = CA:FALSE

keyUsage         = $PURPOSES

nsCertType       = $CERTTYPE

EOT

# Создаём запрос на сертификацию

$REQ -new -key tmp.key -config cfg -rand $RAND -out $CN.pem

# Этот файл лучше удалить побыстрее: мало ли чего...

rm -fr /tmp/.rnd

if [ $? -ne 0 ]; then

    echo "Failed to make a certificate due to error: $?"

    popd > /dev/null

    rm -fr $TMP

    exit $?

fi

# Подписываем сертификат сертификатом сервера

 $X509 -req -in $CN.pem -CA $CA -CAkey $CAkey -extfile cfg -days $DAYS -out $OUTDIR$CN.pem

chmod 0400 $OUTDIR$CN.pem

chown root:root $OUTDIR$CN.pem

# Шифруем секретный ключ

$RSA -in tmp.key -des3 -out $OUTDIR$CN-key.pem

chmod 0400 $OUTDIR$CN-key.pem

chown root:root $OUTDIR$CN-key.pem

# Выполняем заключительные действия

popd > /dev/null

rm -fr $TMP

echo -e "Generation complete, go to $OUTDIR and give to client $CN his certificate and

n private key (for windows users you should use openssl pkcs12 utility)"

Дополнительные свойства, описанные в скрипте (v3_req), означают, что клиент может использовать сертификат для подписывания и шифрации, но его сертификат не является CA-сертификатом. Для CA-сертификата значение basicConstraits должно быть равно CA:TRUE (об этом забывать нельзя!). Поле nsCertType определяет дополнительные назначения данного ключа (для использования в качестве клиента, подписывания, использования в почтовых сообщениях). Для CA-сертификатов обычно применяют следующие значения nsCertType: sslCA, emailCA. Для ssl ключей серверов (например, апача) используется значение nsCertType = server. Полученный таким образом сертификат клиента будет содержать информацию о поставщике сертификата (то есть о вашем сертификате организации). Клиенту необходимо будет передать его сертификат, его секретный ключ (зашифрованный!) и ваш сертификат организации. Для клиентов Microsoft необходимо ещё и перевести сертификаты в формат PKCS#12. Для этого воспользуемся командой openssl pkcs12:

openssl pkcs12 -export -in client.pem -inkey client-key.pem -out client.p12 -name "Client certificate from our organization"

Для обратного преобразования используется синтаксис:

openssl pkcs12 -in client.p12 -out client.pem

В выходной файл записываются сертификат клиента, CA-сертификат, секретный ключ клиента (его можно зашифровать опцией -des3, -idea и т. д.). Такое поведение позволяет использовать для вывода только формат pem (маркеры здесь обязательны!). Для экспорта сертификата организации можно воспользоваться командой pkcs12 ( конечно же без параметра inkey), можно также обработать сертификат организации base64 и сохранить в файле .cer (openssl x509 -in CA.pem -outform DER -out CA.cer).

В openssl существует компонент управления s/mime сообщениями, называющийся openssl smime. Данная утилита позволяет зашифровывать, расшифровывать, управлять ЭЦП и MIME-заголовками писем. Приведу опять же несколько примеров её использования:

openssl smime -sign -in mail.txt -text -from CEBKA@smtp.ru -to user@mail.ru -subject "Signed message"

-signer mycert.pem -inkey private_key.pem | sendmail user@mail.ru

Подписывает сообщение -in (в текстовом виде) и подписывает (-sign) его с помощью сертификата (-signer) и секретного ключа (-inkey). Вывод идёт непосредственно к sendmail, для этого определены MIME-заголовки from, to и subject.

openssl smime -verify -in mail.msg -signer user.pem -out signedtext.txt

Проверяет подпись в файле -in, записывает сообщение в файл -out, а полученный сертификат – в файл -signer (для проверки s/mime сообщения не требуется ничего, кроме него самого, так как ЭЦП s/mime содержит публичный ключ!).

openssl smime -encrypt -in mail.txt -from CEBKA@smtp.ru -to user@mail.ru -subject "Encrypted message"

-des3 user.pem | sendmail user@mail.ru

Шифрация файла -in с помощью сертификата получателя user.pem, используя алгоритм des3. Вывод программы посылается непосредственно в sendmail.

openssl smime -decrypt -in mail.msg -recip mycert.pem -inkey private_key.pem -out mail.txt

Расшифровка файла -in с помощью секретного ключа -inkey и сертификата -recip (ваш собственный сертификат).

Есть альтернатива не указывать smime-заголовки from, to и subject. Можно просто указать необходимый файл -out и добавить заголовки с помощью программы sendmail вручную. Кроме этого, есть ещё одна деталь использования smime: некоторые почтовые клиенты используют в качестве подписи вложение в формате PKCS#7 (чаще всего закодированное base64). В таком случае необходимо применять smime следующим образом:

openssl smime -verify -inform [PEM | DER] -in signature.pem[der] -content mail.txt

PEM используется для стандартного формата PKCS#7, а DER заставляет произвести дополнительную обработку base64. Учтите, что в данном случае файл -in представляет собой только подпись (аттачмент), а -content – непосредственно текст письма. Можно также заставить smime подписывать сообщения подобным образом, если указать опцию -pk7out (PEM-формат). Для преобразования PKCS#7 структуры из формата PEM в формат DER можно воспользоваться утилитой openssl base64 (обратное преобразование достигается за счёт использования опции -d).

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


Комментарии
 
  09.01.2011 - 01:12 |  Сергей

Хорошая статья по OpenSSL, первая подробная инструкция на русском по OpenSSL, которую я нашел.

Спасибо, Всеволод!

  20.01.2011 - 12:56 |  anonymous

Хорошая статья, написана понятным языком. Автор, так держать!

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

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru