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

 

В этой статье я подробно опишу как использовать шифрование при передаче сообщений по сетям на основе XMPP с помощью пакета GnuPG. Показана процедура генерации ключевых пар под Windows, установка ключей в клиент Psi, проверка подписанного присутсвия, передача шифрованного сообщения.

Мотивация

Для чего может понадобится шифрование сообщений?

1. Так как сеть XMPP федеративная и каждый может основать свой узел, то ставится вопрос доверия администратору данного сервера. Сервер могут сломать, сам админ может подбарижить данными и т.д.
2. XMPP набирает популярность в качестве внутрикорпоративного обмена. Может быть сервер и не имеет выхода в Интернет, но никто не застрахован от приезда Party-van с маски-шоу внутри
3. Цифровая подпись повышает надёжность идентификации. То есть вы точно знаете что в данный момент за компьютером сидит именно тот человек, который вам дал ключ, а не тот кто ломанул его аккаунт или воспользовался его отсутсвием его за компьютером

Данная статья, не направлена на решение каких-либо фундаментальных проблем, но помогает, прилагая минимум усилий, автоматизировать сборку пакетов для вашего публичного репозитория.
Допустим, вы собираете для ваших любимых пользователей десять пакетов, да каждый под два дистрибутива (допустим, Debian unstable и Ubuntu jaunty), да еще и каждый под две архитектуры (amd64 и i386). Помните, мы с вами узнали про замечательный инструмент для создания репозиториев — reprepro. Так вот с тех пор он так и не научился включать в репозиторий пакеты пачками — только по одному. А это значит, что вам придётся вводить вашу gpg-подпись 10*2*2=40 раз. А как эффективно собирать эти 10 пакетов, особенно, если они обновляются ежедневно?

GnuPG (GNU Privacy Guard ) — открытая реализация PGP, совместимая со стандартами OpenPGP ( RFC 2440 ). GnuPG позволяет шифровать, расшифровывать, подписывать и верифицировать электронные сообщения при помощи пар ключей ( RSA по-умолчанию ). Наиболее частое применение GnuPG — в шифровании электронной почты и проверки подписи файлов, выложенных для скачивания. Но есть возможность использовать и в других протоколах: например, PSI (Jabber-клиент) поддерживает GnuPG и позволяет поточно шифровать переговоры.

Рассмотрим установку и первичную настройку GnuPG для трёх ОС: Windows, Mac OS X и Linux.
Подразумевается, что читатель имеет достаточные знания для того, чтобы выполнить несколько команд в консоли ОС (CMD/Terminal/xterm соответственно).

На мой параноидальный взгляд по возможности всё общение по почте и IM должно быть зашифровано. (Не потому, что мне есть что скрывать, а просто потому, что я не вижу причин показывать свои сообщения соседу Пете, вне зависимости от того, где он работает — нигде, у провайдера, или в спецслужбе.) Для почты это PGP/GPG, для IM это OTR. Но это шифрование призвано защищать сообщения в процессе передачи по сети, а не на винте в почтовом ящике/логах IM. На винте от него толку нет, одни неприятности — медленный поиск в сообщениях (если в вашем MUA поиск вообще работает в зашифрованных письмах), невозможность обрабатывать почтовый ящик простыми скриптами, etc. Если есть необходимость шифровать данные у себя на винте, то для этого есть другие, более подходящие и универсальные средства, чем PGP для части писем.

Поскольку PGP требуется только во время передачи по сети, то было бы идеальным решением шифровать/дешифровать письма в момент приёма/передачи, т.е. используя локальный POP3/SMTP relay сервер. В этом случае все почтовые клиенты (MUA) автоматически получили бы «поддержку PGP», и при этом ничего о PGP сами не знали, и работали с не зашифрованными письмами. Под Windows такой сервер есть — GPGrelay. Под *NIX я аналога найти не смог. Есть утилитка kuvert, которая может автоматически шифровать исходящую почту, но утилитки для дешифровки входящей я не нашёл.

Но девиз mutt не зря «All mail clients suck. This one just sucks less.» — мне удалось с помощью его гибкости, небольшого вспомогательного скрипта для qmail, и такой-то матери решить эту, на первый взгляд банальную, задачку.

Знаменитый криптограф Ади Шамир (буква “S” в аббревиатуре RSA) с коллегами вчера опубликовал научную работу под названием «Извлечение ключа RSA путём акустического криптоанализа с низкой частотой дискретизации» (RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis). За сложным названием скрывается исключительно доступный метод извлечения ключей RSA (в реализации GnuPG) с помощью обычного мобильного телефона или микрофона. Достаточно лишь положить телефон в 30 см от компьютера жертвы. Если использовать качественные микрофоны, то извлекать ключи можно с расстояния до 4 метров.

Часто бывает так, что существует множество различных проектов, которые необходимо регулярно бэкапить.
Но еще чаще бывает так, что поднимать свой собственный сервис резервного копирования лениво, и копии в лучшем случае делаются время от времени, а в худшем — не делаются вообще. Специально для ленивых людей придумали сервисы синхронизации файлов, такие как Dropbox, Yandex.Disk и иже с ними. Суть всегда одна: файл, загруженный на одном привязанном устройстве, появляется на всех остальных. Ура, решение найдено.
Но встает другой вопрос: безопасность загруженного контента. И если за фотки с Майорки можно особо не переживать, то боевую базу 1С так бэкапить чревато. И вот тут, в этой самой статье, есть небольшой HOW-TO про то, как остаться лентяем и сохранить файлы в безопасности.

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

Для создания и обновления магнитного сайта с множеством страниц нам понадобится электронная подпись. Нужна она чтобы обозначить источник и связать между собой страницы сайта. Для её создания и использования можно воспользоваться пакетом GnuPG.

На самом деле патчим gnupg и libgcrypt…

Когда-то давным давно, чтобы использовать 8192 и 16384 RSA ключи я правил размер в keygen.c и размер SECMEM буффера по соседству. Дела давно минувших дней, теперь SECMEM вынесена в config.h и именуется SECMEM_BUFFER_SIZE.

В итоге после скачивания верии 2.0.29 под свежий debian 8.3, за место убитой 12й убунты апдейтом на 14ую, я быстренько подкрутил размер ключика и размер буфера и радостно сгенерировал на 5200U 16кбит ключ за 18 (или 19) минут, что раньше занимало 45-50 минут на P6200.

Но вот 32кбит дали мне пачку ошибок. Свободное время есть — разбираемся.

Команда GnuPG Project опубликовала сообщение о том, что в популярной библиотеке Libgcrypt содержится критическая уязвимость. Ошибка была обнаружена экспертами Технологического института немецкого города Карлсруэ Феликсом Дёрре (Felix Dörre) и Владимиром Клебановым.

Уязвимость содержится в генераторе случайных чисел Libgcrypt — она позволяет атакующему, который получил 4640 битов из генератора легко предсказать следующие 160 бит его вывода. Это открывает возможность для взлома ключей шифрования. Ошибка присутствует в Libgcrypt и GnuPG версий, выпущенных до 17 августа 2016 года, для всех платформ. Как указано в сообщении GnuPG Project, этот баг существует с 1998 года.

С появлением библиотеки GCrypt-1.7.0 с поддержкой российской криптографии (ГОСТ 28147-89, ГОСТ Р 34.11-94/2012 и ГОСТ Р 34.10-2001/2012), стало возможным говорить о поддержке российского PKI в таких проектах как Kleopatra и KMail.

KMail – это почтовый клиент, который для обеспечения безопасности переписки позволяет подписывать и шифровать сообщения по протоколу S/MIME. И то и другое базируется на архитектуре PKI, сертификатах X509 и протоколах CMS/PKCS#7:

Об авторе: Филиппо Валсорда занимается криптографией и TLS, называет себя «послом urandom», входит в криптогруппу компании Cloudflare, поднял известный сервис для тестирования на уязвимость Heartbleed. Вы могли встречать его на конференциях по криптографии и компьютерной безопасности или под ником @FiloSottile на Github и в твиттере

Спустя годы мучений с GnuPG с различным уровнем энтузиазма я пришёл к выводу, что оно не стоит того, и я сдаюсь. По крайней мере относительно концепции долговременных ключей PGP.

Речь не о самой программе gpg и не о криптографических инструментах в принципе. Многие писали на эту тему. Я говорю о модели долговременных ключей PGP, будь она гарантирована сетью доверия, отпечатками открытых ключей или моделью TOFU — неважно. Я говорю о том, что она не подходит для меня лично.

Я вспомнил что не рассказал важную часть для обеспечения возможности общения и обновления контента в P2P сетях.

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

Как это работает

Шаблон маяка создаётся однократно и используется для создания маяков для связи с автором.

Общий алгоритм получения

1. Публикуется шаблон маяка.
2. Формируется маяк.
3. Поиск этого маяка и файла с хешем маяка в имени.
4. Загрузка найденных файлов или просмотр шары источников маяка.

Общий алгоритм отправки такой

1. Пишем сообщение.
2. Шифруем открытым ключом адресата.
3. Формируем маяк по шаблону адресата.
4. Получаем хеш от маяка и вставляем в имя файла с сообщением.
5. Публикуем маяк и файл с сообщением в p2p сетях.

Наше сообщение и маяк свободно могут копировать другие участники сети. Так как оно зашифровано они не смогут его прочитать но помогут его держать онлайн пока его не получит адресат.

Статья для подписчиков LWN

Хотя население в целом практически не использует OpenPGP, но это критический элемент безопасности, особенно для дистрибутивов Linux. Например, центральный репозиторий Debian проверяет каждый пакет с помощью OpenPGP-ключей мейнтейнера, а затем подписывает его своим ключом. Если у пакетов, которые включаются в ветку, тоже есть такие подписи, то создаётся полноценная цепочка доверия от изначального разработчика до пользователей. Кроме того, пулл-реквесты в ядро Linux тоже верифицируются цифровыми подписями. Поэтому ставки высоки: если скомпрометирован ключ для подписи релиза или хотя бы ключ единственного мейнтейнера, следствием может стать разрушительная атака на много машин.

Это привело сообщество Debian к лучшему пониманию хороших практик работы с криптографическими подписями (которые обычно создаются в программе GNU Privacy Guard, также известной как GnuPG или GPG). Например, слабые (менее 2048 бит) и уязвимые ключи PGPv3 в 2015 году удалили из связок ключей, а среди разработчиков Debian широко распространена практика взаимной подписи ключей при личной встрече. Но даже у разработчиков Debian, кажется, отсутствуют общепринятые правила хранения критического секретного материала, как видно по дискуссии в списке рассылки debian-project. Эта дискуссия сводится к единственному простому требованию: где взять «руководство по хранению электронных ключей для чайников»? Электронные аппаратные ключи или карты-ключи, как мы их здесь называем — это маленькие устройства, позволяющие хранить ключи в офлайне и представляющие собой один из вариантов защиты секретного материала, то есть ключа. В этой статье я постараюсь поделиться своим опытом в данной области и разъяснить проблему, как хранить эти драгоценные секретные ключи, которые в случае компрометации подвергают опасности миллионы компьютеров по всему миру.

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

GPG (также известный как GnuPG) создавался как свободная альтернатива несвободному PGP. GPG используется для шифрования информации и предоставляет различные алгоритмы (RSA, DSA, AES и др.) для решения этой задачи.

Вернер Кох

Вернер Кох, бессменный автор и управляющий проекта GNU Privacy Guard (GPG) для шифрования и цифровой подписи информации (писем, файлов и др.), успешно получил финансирование для продолжения работы. Кроме краудфандинга, принёсшего ему $150000, он получил $60000 от фонда Linux и ежегодные гранты от Facebook и Stripe по $50000.

Вчера вечером состоялся выпуск минорной версии программы GnuPG 2.1.2 для шифрования почты и создания электронных цифровых подписей. Казалось бы, в чём особый повод для радости? А он есть. Ведь этой версии, как и всех последующих, вполне могло и не существовать.

Дело в том, что криптографическую программу GnuPG вот уже 17 лет в одиночку пишет немецкий программист Вернер Кох (Werner Koch). Программист живёт в городке Эркрат на западе Германии, сейчас ему 53 года.

Мы продолжаем разговор об альтернативе openssl и речь пойдет о библиотеке libksba, которая входит в состав GnuPG. Библиотека libksba предоставляет высокоуровневый интерфейс для работы с такими объектами инфраструктуры открытых ключей как сертификаты, запросы на сертификаты, электронная подпись (CMS/PKCS#7). Однако, в отличии от библиотеки GCrypt, в которой реализована поддержка российских криптографических алгоритмов, то в libksba отсутствует реализация рекомендаций ТК-26 по использованию алгоритмов ГОСТ Р 34.10-2001/2012, ГОСТ Р 34.11-94/2012 в таких объектах ИОК как сертификаты, запросы на сертификаты, объекты PKCS#7/CMS (подписанные и/или шифрованные документы и т.п).

Неумолимо приближается час «Ч»: «использование схемы подписи ГОСТ Р 34.10-2001 для формирования подписи после 31 декабря 2018 года не допускается!». И вот, наконец, 16 июля 2018 г. на сайте Федерального ситуационного центра электронного правительства появилось Уведомление о начале выпуска сертификатов ключей проверки электронных подписей подчиненных удостоверяющих центров на головном удостоверяющем центре в соответствии с ГОСТ Р 34.10-2012. Правда, все равно не ясно когда же прекратится выпуск старых сертификатов. Но «процесс пошел» и это радует.