 |
|
|
|
Теория и практика 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 бит). Среди алгоритмов симметрического шифрования наиболее распространены следующие:
Алгоритмы, использующие ключи длиной до 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 можно делать следующее:
Проверять работы серверов и клиентов ssl – команды s_client, s_server. Cуществует также несколько вспомогательных утилит ssl:
openssl speed md5 rsa idea blowfish des 3des sha1 В конце выводится общая скорость работы различных алгоритмов (в 1000-х байт в секунду), для обработки различной длины блоков. Вот результат работы тестов скорости на моём домашнем компе (Celeron 366), на других компах значения будут другими: Таблица 1
Таблица 2. Проверка алгоритмов асимметрического шифрования
# openssl rand 5 Wеб~ #
Обычно в настоящее время используются алгоритмы групп 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
После этого секретный ключ зашифровывается и записывается в файл (в текстовом виде). В начале ключа указывается алгоритм шифрования. Для создания публичного ключа 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 – это одно из символических имён симметрических шифров. Наиболее популярными являются следующие:
Для указания входного и выходного файлов используются опции -in и -out соответственно. Пароль для шифрования вводится с клавиатуры (можно указать в командной строке параметром -k, но это очень плохо по соображениям безопасности, так как большинство шелов умеют сохранять историю командной строки, на мой взгляд, намного лучше ввести пароль непосредственно перед шифрованием). Учтите, что пароль не спрашивается при обработке файла base64, так как шифрования не происходит. Для расшифровки зашифрованных данных примените openssl cipher с опцией -d (алгоритм шифрования и дешифрования должен совпадать!), а для одновременной обработки данных base64 можно воспользоваться опцией -a. Шифрование по умолчанию происходит с подмешиванием (подсолением), для выбора алгоритма подмешивания используется случайная соль (salt), поэтому, если вы шифруете один и тот же файл в разное время одним и тем же алгоритмом и паролем, то результаты скорее всего будут разными (это затрудняет атаку по словарю). Также по умолчанию используется cbc режим алгоритмов, когда ключ меняется в течение всего сеанса работы согласно передаваемым данным. Приведу несколько примеров:
# openssl des3 -in file -out file.des3
# openssl des3 -d -in file.des3 -out file
# openssl bf -a -in file -out file.bf64
# openssl bf -a -d -in file.bf64 -out file Для вычисления хешей используется команда openssl dgst -hashalg или краткая форма openssl hashalg (первая команда может также выполнять манипуляции с ЭЦП, но об этом далее). Обычное использование данной команды таково openssl hashalg [-c] file[s]. Вычисляется хеш сообщения фиксированной длины в виде одной строки или, если указана опция -c, строки, разделённой на пары HEX чисел двоеточием. Среди алгоритмов хеширования могут применяться следующие:
Опять же приведу пару примеров:
# openssl md5 -c file MD5(file)= 81:fd:20:ff:db:06:d5:2d:c3:55:b5:7d:3f:37:ac:94
# 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:
Подписать запрос на сертификацию (-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
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 этого будет достаточно. |
ВСЕВОЛОД СТАХОВ| Комментарии |
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
