ОМСКАЯ ГРУППА ПОЛЬЗОВАТЕЛЕЙ LINUX » scripts http://omsklug.com Свобода - это ответственность. Вот почему все её так боятся. Бернард Шоу Fri, 10 Nov 2017 17:30:02 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 Криптография с использованием ключей SSH http://omsklug.com/2015/09/ssh-crypto-pgp-for-poors/ http://omsklug.com/2015/09/ssh-crypto-pgp-for-poors/#comments Sun, 20 Sep 2015 16:18:42 +0000 Shroom http://omsklug.com/?p=1932 .local p {text-align: justify!important; text-justify: inter-word!important;} .local a {color: rgb(16, 8, 96)!important;} .local a:visited {color: Gray!important;} .local a:hover {text-decoration: underline; color: Blue!important;} .local code {font-family: Monospace,Courier!important;}

…или «PGP для бедных»

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

История вопроса

Итак, давным-давно, кажется в прошлую пятницу… Хотя нет. На самом деле в начале мая этого года… Так вот, именно в то время Родригес задался вопросом, можно ли в рамках концепции криптографии с открытым ключом использовать для шифрования ключи ssh. Они же по умолчаню есть практически всегда, чего не скажешь, например, о PGP/GnuPG. И, как оказалось, это возможно! В общем, академический интерес Родригеса был удовлетворён почти сразу же, а вот у меня до практческой реализации идеи руки дошли только сейчас.

Впрочем, для того, чтобы что-то зашифровать и подписать, ssh будет маловато: в любом случае нужно будет поставить дополнительно хотя бы openssl. Не будем спрашивать, почему бы не поставить GnuPG, раз уж в любом случае нужно что-то ставить. Лучше предположим, что шифровать будет какой-нибудь бездомный (в смысле, без ~ и с nologin) робот в автоматическом режиме, и специально для него генерить связку pgp-ключей будет, наверное, слишком жирно. Так что пусть удовлетворяется тем, что есть.

В чём суть

Так чем же удовлетворить себя несчастному одинокому роботу, если GnuPG не стоит, а шифровать хочется? Ответ очевиден: OpenSSL! Более конкретно — модуль rsautl, который позволяет шифровать небольшие клочки данных (в зависимости от типа пэддинга максимум будет составлять 214, 245 или 256 байтов) открытым RSA-ключом. Не нужно быть семи пядей во лбу, чтобы понять, что даже максмальные 256 байтов не пойдут ни в борщ, ни в красную армию. По той простой причине, что их слишком мало. Тем более, что та же openssl enc умеет шифровать симметричными алгоритмами, коих знает туеву хучу, практически ничем не ограниченные тонны информации. Так в чём же фишка?

Фишка, собственно, в асимметричности RSA. То есть, в данном случае не нужно никому передавать по защищённому каналу секрет для расшифровки. В наличии меется открытый ключ, который используется для шифрования и может быть известен неограниченному кругу лиц, а адресат расшифрует файл своим секретным закрытым ключом. Вернее, всё не совсем так. Даже совсем не так. Во-первых, открытым ключом никто сами данные шифровать не будет. Во-вторых, шифровать симметричным алгоритмом всё равно придётся. «Нувыпонели, да?» Это я сейчас пересказываю принцип работы PGP. В общем, те, кто понял, могут переходить прямо к следующему разделу, а всем остальным я предлагаю раскрыть тайну PGP.

А тут на самом деле всё просто. Берём байт 200 какого-нибудь случайного мусора, например, из /dev/random и говорим, что это наш «одноразовый сессионный ключ». Одноразовый, потому что он действительно будет использован только один раз, в данном конкретном случае. При этом его на самом деле никто не знает. То есть, он нигде не светится. Так вот. Берём этот ключ и шифруем на нём всё, что нам нужно. После этого начинается немного магии. Мы берём открытый ключ адресата и на нём шифруем сессионный ключ. Voilá! После этого можно подшить зашифрованный сессионный ключ к зашифрованным данным и отправлять это всё по любым каналам связи: всё равно никто ничего расшфровать не сможет.

На приёмной стороне происходит нечто подобное, но в обратном направлении. Сначала берём закрытый ключ адресата и расшифровываем им сессионный ключ. А после этого естественным образом сессионным ключом расшифровываем данные. Собственно, всё… Вся магия куда-то испарилась, как обычно… Ну а дабы окончательно разогнать остатки мистического огненного тумана, ниже даны команды для осуществления подобного безобразия дома. Для определённости условимся, что данные, подлежащие закрытию, находятся в файле data, сессионный ключ — в файле skey (да, да, я знаю, что так делать нельзя и всё такое, но это просто общая схема, в настоящем скрипте «всё по-другому»), а цифровая подпись — в файле signature. Также будем считать, что открытый ключ записан в файле rsa_key.pub, а закрытый — rsa_key.priv.

# Encryption:
openssl [здесь любимый алгоритм шифрования] -pass file:skey -in data -out data.encrypted
openssl rsautl -encrypt -pubin -inkey rsa_key.pub -in skey -out skey.encrypted
# Decryption
openssl rsautl -decrypt -inkey rsa_key.priv -in skey.encrypted -out skey
openssl [здесь любимый алгоритм шифрования] -d -pass file:skey -in data.encrypted -out data

Если хочется ещё и добавить цифровую подпись, это можно сделать таким образом:

openssl [здесь любмый хзш] -sign [ЗАКРЫТЫЙ ключ ОТПРАВИТЕЛЯ] -out signature -binary data

Проверять, соответственно, так:

openssl [здесь любмый хзш] -verify [ОТКРЫТЫЙ ключ ОТПРАВИТЕЛЯ] -signature signature data

Кстати, обратите внимание на то, что для шифрования используются ключи адресата, а для подписи — отправителя.

Собственно, скрипт

Реализация указанной идеи с помощью костылей shell и openssl повлекла за собой некоторое количество ограничений, о которых необходимо сказать сразу же. Из самого названия модуля rsautl легко можно сделать вывод, что использоваться будут только RSA-ключи. Это не самый удобный вариант, поскольку ssh-keygen умеет генерить не только RSA, но и DSA, а также ключи на основе эллиптических кривых, как, например, ECDSA и ED25519. И этот факт нужно учитывать, если всё-таки захочется шифровать файлы столь извращённым способом. В отношении подписи ограничения не столь суровы: не поддержвается только ED25519.

А собственно скрипт находится в репе на гитхабе. Ничего сверхъестественного, всё достаточно прозрачно и понятно. Если что-то всё-таки непонятно, можно запустить эту штуку с ключом --help, почитать ReadMe или, в конце концов, заглянуть в исходный код. Собственно, ради этого он и находится в свободном доступе.

Всем спасибо, все свободны!


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

]]>
http://omsklug.com/2015/09/ssh-crypto-pgp-for-poors/feed/ 0
LUKS Header Backup Helper http://omsklug.com/2015/09/luks-header-backup-helper/ http://omsklug.com/2015/09/luks-header-backup-helper/#comments Sun, 13 Sep 2015 18:02:20 +0000 Shroom http://omsklug.com/?p=1908 .local p {text-align: justify!important; text-justify: inter-word!important;} .local a {color: rgb(16, 8, 96)!important;} .local a:visited {color: Gray!important;} .local a:hover {text-decoration: underline; color: Blue!important;} .local code {font-family: Monospace,Courier!important;}
Связка ключей

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

Потеря — это всегда боль…

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

Особенно это касается систем хранения данных с шифрованием разделов. Просто потому, что зашифрованные данные особенно уязвимы к ошибкам. Да, безусловно, некоторые алгоритмы позволяют восстановить поток после сбойного блока. Но этот блок в любом случае будет безвозвратно потерян. И особенно это страшно, если речь идёт об ошибках в области заголовков LUKS. Ведь если ошибка появилась в том месте, где размещены слоты для ключей, это в контексте восстановленя данных практически равносильно низкоуровневому форматированию. Да, это очень удобно, когда срочно необходимо избавиться от информации. А когда эта самая информация, зашифрованная криптостойким алгоритмом с 256-битным ключом, позарез нужна для работы крупного предприятия? Что же делать в таких случаях?

Выход есть!

Во-первых, без паники! Если вы используете любое ПО для резервного копирования данных, в худшем случае вы потеряете время на развёртывании копии системы. Не имеет значения, bacula ли это будет, backuppc или голый rsync. Главное, что важные данные, которые требуются ежедневно, будут сохранены в надёжном месте. Безусловно, на другой машине. Желательно в другом здании. Ещё лучше — в другой стране в надёжном дата-центре.

«Но как же,» — спросите вы, — «это связано с LUKS?» Собственно, напрямую. Поскольку cryptsetup умеет делать бэкапы LUKS-заголовков и, соответственно, восстанавливать их. И что самое важное, восстановление заголовка из бэкапа может спасти диск даже в том случае, когда заголовок был просто полностью забит мусором из /dev/random. Да-да! Я лично проверял. Всё работает. Кстати, в связи с этим возникает некая идея «уничтожения» данных с последующим их «волшебным восстановлением»… Ну там если «маски-шоу»… Или если подзаработать захотелось… Гм… Впрочем, ближе к делу. Итак, вот они — две волшебные команды, которые спасут ваши данные/время/деньги/задницупрочие причиндалы.

Сделать бэкап LUKS-заголовка:

cryptsetup luksHeaderBackup <LUKS_DEVICE> --header-backup-file <header_file_name>

Восстановить LUKS-заголовок из бэкапа:

cryptsetup luksHeaderRestore <LUKS_DEVICE> --header-backup-file <header_file_name>

Да, есть ещё одна дополнительная возможность, которая считается весьма опасной. И правильно, в сущности, считается. Потому что это не что иное, как создание мастер-ключа. Удобно, на самом деле: можно на одном мастер-ключе наклепать шифрованных разделов и не бояться забыть пароли. Да вообще пароли можно не знать: нагенерить их автоматически из /dev/random и поскидывать на флэшки, которые вставлять по мере надобности при загрузке. В случае чего мастер-ключ позволит расшифровать раздел, даже без знания обычных ключей. Однако, очевидно, что это палка о двух концах: посеял файлик с мастер-ключом, и все соответствующие разделы можно считать скомпрометированными. Ну либо мёртвыми. И неизвестно ещё, что хуже. Кстати, вот команда для сдампливания мастер-ключа:

cryptsetup luksDump --dump-master-key <LUKS_DEVICE>

Да, вот так просто можно подарить кому-то все свои заботливо зашифрованные данные.

Ну так, собственно, к чему это я всё? К тому, что следующим логичным шагом в деле защиты данных будет

Автоматизация

Собственно, отсюда и начинается та самая реклама, про которую был соответствующий тэг.

Итак… [барабанная дробь] Встречайте! Скрипты для автоматического создания бэкапа заголовков LUKS и мастер-ключа! А на…зачем, собственно, нужны какие-то там непонятные скрипты, если всё делается буквально в полторы-две команды? Отличный вопрос!

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

Подробно работу со скриптами описывать не буду, поскольку всё есть в Readme. Однако, на всякий случай отмечу, что кроме coreutils и cryptsetup, скриптам для работы понадобится ещё и xxd. А если хочется ещё и создать тома для восстановления архива, то нужно будет поставить par2. Больше никаких сложностей возникнуть не должно.

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


P.S.: Этот пост посвящается памяти всех данных, безвозвратно утерянных вследствие обстоятельств непреодолимой силы или просто пользовательского/админского раздолбайства (что по сути одно и то же).

]]>
http://omsklug.com/2015/09/luks-header-backup-helper/feed/ 0
Фильтры для GIMP от elsamuko http://omsklug.com/2011/10/elsamuko-gimp-filters/ http://omsklug.com/2011/10/elsamuko-gimp-filters/#comments Tue, 04 Oct 2011 15:29:32 +0000 Сторож http://omsklug.com/?p=468 http://sites.google.com/site/elsamuko/gimp

Неплохой набор фильтров для GIMP, возможно лучшего редактора для дистрибутивов GNU/Linux. Есть неплохие вещи, например, фильтр ломографии, скрипт симуляции пленки, скрипт симуляции Technicolor, скрипт стилизации под Obama “Hope”, скрипт стилизации Che Guevara./

]]>
http://omsklug.com/2011/10/elsamuko-gimp-filters/feed/ 2