Открытый и закрытый ключ: роли и хранение

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

Закрытый ключ — это и есть ваша личность в криптографической системе, и его утечка равна потере контроля. Хранить его следует в защищённом виде: в файле, зашифрованном парольной фразой, в системном хранилище, в аппаратном токене или смарт-карте, где ключ вообще не покидает устройство. Не отправляйте его в мессенджерах, не кладите в общий репозиторий с кодом, не копируйте на общие диски. Права доступа к файлу ключа в Linux ограничивают командой вроде chmod 600, иначе, например, клиент SSH откажется его использовать; подробнее на страницах klyuchi-ssh и prava-dostupa-chmod.

Делайте резервную копию в надёжном месте: потеря единственной копии означает потерю доступа к данным.

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

Публикуйте свободно, но проверяйте подлинность: подмена чужого открытого ключа своим позволяет перехватывать данные. В веб-среде эту задачу решают сертификаты: центр сертификации заверяет соответствие между именем сайта и ключом, а браузер проверяет цепочку; см. tsentr-sertifikatsii и tsepochka-doveriya. В PGP подлинность подтверждают сверкой отпечатка ключа, короткой строки, вычисленной из ключа, лично или по независимому каналу. Для SSH сервер при первом подключении показывает отпечаток, и его стоит сверять, а не принимать вслепую.

Ключи не вечны. Их периодически заменяют, а при подозрении на компрометацию отзывают: сертификат заносят в список отозванных или проверяют через специальный протокол статуса, для ключей PGP публикуют сертификат отзыва, заготовленный заранее. Для SSH достаточно удалить открытый ключ из списка разрешённых на сервере. Регулярная смена ограничивает ущерб, а раздельные ключи для разных задач не позволяют одной утечке затронуть все сервисы.

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

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

Для доступа к серверам ключевую пару создают командой ssh-keygen. Программа предложит место сохранения и парольную фразу. В результате появятся два файла: закрытый без расширения и открытый с расширением pub. Содержимое открытого файла добавляют в список разрешённых ключей на сервере, после чего вход происходит без пароля учётной записи, а подтверждается владением закрытым ключом.

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