Шифрование бэкапов с использованием age и о ценности простоты

Немного очевидного

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

Крипто Дисклеймер

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

Кто не в курсе, рекомендую потратить 2-3 минуты и немного ознакомиться с ECB-пингвином.

Я однажды так влетел (к счастью, ошибку нашел сам). Выбрал режим склейки блоков ECB (они там разные есть ECB, CBC, CTR, GCM, XTS) — я логично решил, что криптостойкость может быть разная, но совсем уж фигни в openssl не будет. И ошибся. Криптография и популярные стандартные крипто-инструменты позволяют выстрелить себе в ногу, позволяют обмануть себя ложным чувством безопасности.

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

Что такое age и можно ли ему доверять?

age (произносится не «эйдж», а удобно, по-русски, «аге», с «г» как в «гиф») это новый, популярный инструмент шифрования (17k звезд звезд на github). age использует связку алгоритмов ChaCha20 для симметричного шифрования с алгоритмом имитовставки (Message authentication code, MAC, если по нашему) Poly1305 (RFC7539) от D. J. Bernstein. Того самого, который изобрел ed25519, который вы (будем надеяться) используете в ssh ключах. Кстати, этот ed25519 используется так же и в wireguard и в age тоже.

Установить можно просто через apt install age .

Автор — утилиты (можно ли ей доверять?) Filippo Valsorda работал в крипрографической команде Cloudflare, возглавляет Go security team в Google.

Просто используем!

Сначала — самое простое шифрование, просто паролем, для самых маленьких.

# encrypt $ age -p -o paris.jpg.age paris.jpg  Enter passphrase (leave empty to autogenerate a secure one):  Confirm passphrase:   # decrypt $ age -d -o paris-decrypted.jpg paris.jpg.age  Enter passphrase:

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

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

Мы не хотим хранить какие-то приватные или симметричные ключи на сервере.
Несколько человек в компании («получатели») должны иметь возможность расшифровать бэкапы. Чтобы даже если один ушел из команды, кто-то другой может расшифровать бэкап.
Мы не хотим использовать какой-то один «супер-ключ» и давать его всем. Как правило, такой ключ быстро утекает (через взломанные мессенджеры, переписки) и что самое плохое — мы даже не можем узнать, от кого он утек. Каждый получатель должен иметь возможность расшифровать своим индивидуальным ключом, который он нигде не светит.

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

Откуда взять ключи? Первый вариант — сгенерировать их: age-keygen -o key.txt создаст пару публичных и приватных ed25519 ключей. Но… а зачем? В наше время у всех есть SSH ключ в формате ed25519 ну или на худой конец RSA. Не будем плодить ключи, будем использовать ключи SSH, которые у нас уже есть, age это умеет! Получателей к шифрованному файлу можно добавлять повторяя аргумент -r KEY (значение публичного ключа прямо аргументом передаем), или -R file — где в файле перечислены (один или несколько) публичные ключи. Ваш ~/.ssh/id_ed25519.pub вполне подходит в качестве ключа для шифрования. Но мы всех получателей запишем в один файл recipients.txt:

# john doe ssh-ed25519 AAAA....  # my key ssh-ed25519 AAAA....

Да, пустые строки и решетки — можно. и даже ~/.ssh/authorized_keys вполне подходит в качестве такого файла.

Ну и поехали:

$ age -o paris.jpg.age -R recipients.txt paris.jpg

Полученный paris.jpg.age файл можно свободно заливать в ваш любимый файлообменник, хоть в S3, хоть в дропбокс хоть в skype.

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

$ age -d -o paris.jpg -i ~/.ssh/id_ed25519 paris.jpg.age

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

Почему мне нравится age (холиварное немного)

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

Во-первых — age, это просто и дешево и быстро в реализации. Как говорил Борис Бритва про криптографию: простота это хорошо, простота — это надежно! С практической точки зрения, age, это такой инструмент, про который вы сейчас прочитали статью, через 15 минут поигрались и увидели, что он работает и к вечеру начали качественно и надежно шифровать бэкапы. Это — работает. Какие-то сложные схемы — там уже бОльшая вероятность, что пока вы с ними разберетесь на достаточном уровне, там возникнут другие важные дела, задачи, вы переключитесь и просто не сделаете никакое шифрование. Поэтому — я сторонник простых и надежных решений.

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

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

Я не пользовался активно PGP/GPG, кроме как поиграться, но пользовался openssl. Опыт был настолько болезненный и травмирующий, что моя психотравма от использования openssl для работы с X.509 сертификатами сублимировалась в проект showcert (статья на хабре про showcert), 70+ звезд на гитхабе. Все типовые операции с сертификатами, от просмотра сертификата из файла или на удаленном сервере и до создания своего CA делаются простыми, короткими интуитивными командами. Сравните:

# you will never forget how to read certificate with showcert showcert habr.com   # two redirections, pipe, two invocations and 5 unneeded options openssl s_client -connect habr.com:443 </dev/null 2>/dev/null | openssl x509 -inform pem -text

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

openssl у меня оставил впечатление не инструмента для решения задачи, а скорее прокладки, CLI-интерфейса к очень богатому зоопарку различных криптографических функций (из которых 99% вам не нужно, а оставшимся 1% вы не понимаете как пользоваться, когда GCM лучше, чем XTS, но можете загуглить и скопировать заклинание из браузера в шелл).

Ниже, в «ссылках для холивара» есть хорошая иллюстрация (stackoverflow), когда длинное «заклинание» с openssl в самом деле шифрует файл. Этот ответ заплюсован, многие тысячи людей копируют и используют его, и только ниже в комментариях к ответу, написано, почему так делать неправильно. Тот самый эффект ECB-пингвина из начала статьи. Люди делают криптографию на основе полуграмотного комментария неизвестно кого, заплюсованного еще более неграмотными в криптографии людьми.

А вот age — это именно утилита для шифрования, инструмент для конкретного предназначения. Не претендует на то, чтоб быть швейцарским ножом, которым можно и звездолет починить, но отлично нарезает сервелат.

Еще, мне очень понравился аргумент из статьи @stargrave2на хабре Libre/OpenPGP vs OpenSSH/age :

Когда мы в последний раз видели чтобы ломали какой-то формат или протокол, потому что в нём был уязвимый шифр? RC4, который нигде и не использовался серьёзно, если были привлечены криптографы? А вот если в протоколе или формате можно согласовывать/выбирать эти алгоритмы, то downgrade атак или уязвимостей в ASN.1 парсерах (из-за вынужденно сложных форматов) мы видели тьму. Решения с моно-алгоритмами просто не подвержены этим атакам.

Почитать по теме и для холиваров age/pgp/openssl

Странички на stackoverflow стоит читать с комментариями

ссылка на оригинал статьи https://habr.com/ru/articles/856222/