Статья для подписчиков LWN
Хотя население в целом практически не использует OpenPGP, но это критический элемент безопасности, особенно для дистрибутивов Linux. Например, центральный репозиторий Debian проверяет каждый пакет с помощью OpenPGP-ключей мейнтейнера, а затем подписывает его своим ключом. Если у пакетов, которые включаются в ветку, тоже есть такие подписи, то создаётся полноценная цепочка доверия от изначального разработчика до пользователей. Кроме того, пулл-реквесты в ядро Linux тоже верифицируются цифровыми подписями. Поэтому ставки высоки: если скомпрометирован ключ для подписи релиза или хотя бы ключ единственного мейнтейнера, следствием может стать разрушительная атака на много машин.
Это привело сообщество Debian к лучшему пониманию хороших практик работы с криптографическими подписями (которые обычно создаются в программе GNU Privacy Guard, также известной как GnuPG или GPG). Например, слабые (менее 2048 бит) и уязвимые ключи PGPv3 в 2015 году удалили из связок ключей, а среди разработчиков Debian широко распространена практика взаимной подписи ключей при личной встрече. Но даже у разработчиков Debian, кажется, отсутствуют общепринятые правила хранения критического секретного материала, как видно по дискуссии в списке рассылки debian-project. Эта дискуссия сводится к единственному простому требованию: где взять «руководство по хранению электронных ключей для чайников»? Электронные аппаратные ключи или карты-ключи, как мы их здесь называем — это маленькие устройства, позволяющие хранить ключи в офлайне и представляющие собой один из вариантов защиты секретного материала, то есть ключа. В этой статье я постараюсь поделиться своим опытом в данной области и разъяснить проблему, как хранить эти драгоценные секретные ключи, которые в случае компрометации подвергают опасности миллионы компьютеров по всему миру.
Зачем хранить ключи в офлайне?
Прежде чем мы в подробностях разберём хранение паролей в офлайне, полезно будет вкратце вспомнить, как работает стандарт OpenPGP. Ключи OpenPGP создаются из главной пары открытого и закрытого ключей, ключа сертификации, который подписывает идентификаторы пользователей, и подключей. Мой публичный ключ, показанный ниже, содержит обычный ключ сертификации/подписи (помечен как SC), а также подключ шифрования (помечен как E), отдельный ключ подписи (S) и два ключа аутентификации (помечены как A), которые я использую в качестве ключей RSA для авторизации на серверах по SSH, спасибо проекту Monkeysphere.
pub rsa4096/792152527B75921E 2009-05-29 [SC] [expires: 2018-04-19]
8DC901CE64146C048AD50FBB792152527B75921E
uid [ultimate] Antoine Beaupré <anarcat@anarc.at>
uid [ultimate] Antoine Beaupré <anarcat@koumbit.org>
uid [ultimate] Antoine Beaupré <anarcat@orangeseeds.org>
uid [ultimate] Antoine Beaupré <anarcat@debian.org>
sub rsa2048/B7F648FED2DF2587 2012-07-18 [A]
sub rsa2048/604E4B3EEE02855A 2012-07-20 [A]
sub rsa4096/A51D5B109C5A5581 2009-05-29 [E]
sub rsa2048/3EA1DDDDB261D97B 2017-08-23 [S]
Все подключи (sub) и идентификаторы (uid) связаны основным ключом сертификации с использованием цифровых подписей с самоаутентификацией. Так что хотя злоумышленник, получивший секретный подключ, может подделать мои подписи или выполнить аутентификацию на других серверах, этот подключ всегда можно отозвать с помощью основного ключа сертификации. Но вот если потерян ключ сертификации, всё пропало: злоумышленник может создавать или отзывать индентикаторы или подключи, как он пожелает. В самом катастрофическом сценарии злоумышленник украдёт ключ и сотрёт ваши копии, получив полный контроль над ключом без какой-либо возможности восстановления с вашей стороны. Кстати, вот почему так важно сгенерировать сертификат отзыва и хранить его в офлайне.
Итак, перенеся ключ сертификации в офлайн, мы уменьшаем возможности атаки на цепочку доверия OpenPGP: повседневные ключи (например, для шифрования почты или цифровой подписи) могут оставаться в онлайне. Если их украдут, то ключ сертификации отзовёт эти ключи без проблем, а сам останется в безопасности. Заметьте, что кража ключа шифрования — это уже другая проблема: даже если мы отзовём подключ шифрования, это повлияет только на будущие зашифрованные сообщения. С помощью украденного подключа злоумышленник сможет прочитать предыдущие зашифрованные сообщения даже если отозвать этот подключ, так что преимущества отзыва сертификатов шифрования более ограничены.
Основные стратегии офлайнового хранения ключей
Учитывая компромиссы безопасности, для снижения риска предлагается хранить критические ключи в офлайне. Но где конкретно? Джонатан Макдауэлл, член группы обслуживания связки ключей Debian, говорит о трёх вариантах: внешний LUKS-зашифрованный том, отключенная от всех каналов связи изолированная система или карта-ключ.
Полнодисковое шифрование вроде LUKS добавляет дополнительный уровень безопасности, скрывая ключ от злоумышленника. Даже хотя секретные связки ключей обычно защищаются парольной фразой, легко распознать, что это — связка ключей. Но если том полностью зашифрован, то злоумышленнику сразу не очевидно, что на устройстве имеются ключи. По словам Шона Уиттона, ещё одним преимуществом LUKS перед обычным шифрованием связки ключей в GnuPG является то, что при создании раздела LUKS вы можете передать аргумент --iter-time для увеличения задержки на формирование ключа (key derivation), что сильно усложняет брутфорс. В самом деле, у GnuPG 2.x нет опции для конфигурации алгоритма формирования ключа, хотя недавно был представлен патч, который позволяет настраивать задержку формирования ключа во время компиляции gpg-agent. Он теперь отвественен за все операции с секретным ключом.
Недостаток внешних томов — излишняя сложность. GnuPG усложняет процесс извлечения секретов из связки с ключами, что делает первичную установку мудрёной и подверженной ошибкам. В версиях 2.x процедура упростилась благодаря новой системе хранения и соответствующим файлам keygrip, но она по-прежнему требует тайного знания внутреннего устройства GPG. Также неудобно использовать секретные ключи, которые хранятся за пределами вашей основной связки ключей. Когда они действительно нужны, GPG не знает, где их теперь найти.
Другой вариант — установить для операций сертификации отдельную изолированную систему. В качестве примера можно привести проект «чистой комнаты» PGP, это действующая система на базе Debian, которую разработал Дэниэл Покок, чтобы запустить центр сертификации OpenPGP и X.509 на обычном оборудовании. Основной принцип — хранить секретные ключи на отдельной машине, которая никогда не подключается к сети и поэтому не подвержена атакам, по крайней мере, в теории. Лично я отвергаю этот вариант, потому что мне кажется, что изолированные системы дают ложное чувство безопасности: всё-таки данные должны как-то попадать в систему и извлекаться оттуда, даже если речь идёт только об извлечении подписей, что подвергает систему атакам.
Точно так же осложняются обновления ОС: чтобы система оставалась безопасной, на изолированный от сети компьютер нужно своевременно устанавливать обновления. Обычно информация распространяется через USB-флешки, что даёт возможность заразить систему через уязвимости вроде BadUSB. С момента заражения есть куча экзотических способов снимать данные, используя светодиоды, инфракрасные камеры или старую добрую атаку TEMPEST. Поэтому я пришёл к выводу, что выгоды с упрощением процедуры, которые даёт изолированная система, не стоят того. Более того, с изолированными системами на самом деле не так просто работать: дже хотя «чистая комната» PGP прошла долгий путь разработки, у неё по-прежнему нет простых скриптов доля подписи или передачи ключей, то есть здесь такая же проблема, как у подхода с внешними зашифрованными томами LUKS.
Преимущества карт-ключей
Я выбрал подход с использованием криптографических ключей-карт: это внешнее устройство, которое обычно подключается через разъём USB, оно хранит секретный ключ и выполняет критические криптографические операции от имени хоста. Например, карта-ключ FST-01 выполняет дешифровку в схемах асимметричного шифрования RSA и ECC, не выдавая хосту материал секретного ключа. По сути, карта-ключ — это миниатюрный компьютер, который выполняет ограниченный набор вычислений для другого хоста. Карты-ключи обычно поддерживают несколько «слотов» для хранения подключей. Стандарт OpenPGP устанавливает три подключа по умолчанию: для подписи, аутентификации и шифрования. В конце концов, на карте-ключе может находиться реальная физическая вспомогательная клавиатура для ввода паролей, так что потенциальный кейлоггер здесь бессилен, хотя мне в руки не попадались карты-ключи с такими клавиатурами.
Можно легко провести параллель между картами-ключами и изолированной системой; по сути, карта-ключ — это изолированная система в миниатюре, которая страдает от таких же проблем. Злоумышленник может перехватить данные на хосте и атаковать устройство таким же способом, если не проще, потому что карта-ключ в реальности находится «в онлайне» (то есть явно не изолирована) после подключения. Однако преимущество перед полностью изолированным компьютером состоит в том, что карта-ключ выполняет только ограниченный набор операций. Так что создать архитектуру открытого аппаратного и программного обеспечения, которое прошло аудит и проверку, гораздо проще, чем с компьютером общего назначения.
Как и изолированные системы, карты-ключи мешают злоумышленнику получить доступ к секретному ключу. Он может обманом заставить карту-ключ подписать или расшифровать какие-то данные, но это возможно только тогда, когда устройство физически подключено к компьютеру, и карта-ключ запросит у пользователя пароль перед совершением операции, хотя может какое-то время кэшировать пароль. В сущности, офлайновые атаки становятся невозможны: чтобы подобрать брутфорсом пароль к ключу, злоумышленник должен получить доступ к компьютеру жертвы и попытаться подобрать пароль здесь, в то время как карта-ключ допускает только ограниченное количество попыток. Она также предоставляет ясный и стандартный интерфейс для хранения ключей в офлайне: одной командой GnuPG материал секретного ключа перемещается на карту-ключ (команда keytocard в интерфейсе --edit-key), в то время как перемещение материала на зашифрованное устройство LUKS или изолированный компьютер представляет собой более сложную процедуру.
Карты-ключи также более полезны при работе с несколькими компьютерами. Общая проблема при использовании GnuPG на нескольких машинах — как безопасно копировать и синхронизировать материал секретного ключа на нескольких устройствах, что порождает новые проблемы безопасности. В конце концов, «правило хорошего тона в криминалистической лаборатории», согласно Роберту Хансену из списка рассылки GnuPG — это «хранить как можно меньше персональных данных на своих системах». Карта-ключ здесь хороша с обеих сторон: вы можете использовать свой секретный ключ на нескольких компьютерах, но не будете хранить его многократные копии. На самом деле Майк Гервиц более категоричен:
«Для пользователей, которым ключ GPG нужен на нескольких машинах, я считаю смарт-карту необходимым устройством. В ином случае пользователь просто увеличивает риск компрометации».
Недостатки карты-ключа
Как заметил Гервиц, в использовании карты-ключа всё-таки есть несколько отрицательных моментов. Другой разработчик Debian Вутер Верхельст чётко их сформулировал:
«Смарт-карты полезны. Они гарантируют, что секретная половина вашего ключа никогда не попадёт на жёсткий диск или любой другой обычный носитель, и поэтому её невозможно украсть (потому что существует только одна копия).
Смарт-карты — это ещё и заноза в заднице. Они гарантируют, что секретная половина вашего ключа никогда не попадёт на жёсткий диск или любой другой обычный носитель, а вместо этого лежит у вас в кошельке, так что каждый раз, когда нужен доступ к ней, вам придётся доставать кошелёк, что занимает больше времени, чем просто запустить GnuPG. Если в вашем ноутбуке нет встроенного кард-ридера, то придётся ещё и доставать кард-ридер из рюкзака или откуда-то ещё».
Под «смарт-картами» здесь имеются в виду старые карты OpenPGP с разъёмами IEC 7816, которые нуждались в специальных кард-ридерах. Новые карты-ключи просто используют обычный интерфейс USB. В любом случае, внешнее устройство привносит новые проблемы: злоумышленник может украсть вашу карту-ключ, вы можете просто потерять её или постирать с грязным бельём. Конечно, ноутбук или компьютер тоже можно потерять, но намного проще потерять маленькую карту-ключ USB, чем целый ноутбук — и я ещё не слышал, чтобы кто-нибудь постирал целый ноутбук в стиральной машине. Когда вы теряете карту-ключ, если нет отдельного сертификата отзыва, то вы полностью теряете контроль над ключом, что будет катастрофой. Но даже если отозвать потерянный ключ, нужно будет создать новый, что означает выстроение с нуля сети доверия для этого ключа — довольно дорогая операция, потому что обычно она включает в себя личную встречу с другими пользователями OpenPGP для обмена отпечатками.
Поэтому следует подумать о создании резервной копии ключа сертификации. Такая же проблема существует для онлайновых ключей. Конечно, у всех есть сертификаты отзыва и резервные копии их ключей OpenPGP… верно? В случае с картой-ключом резервными копиями могут стать несколько карт-ключей, распределённых географически.
Заметьте, что в отличие от изолированных систем, сгенерированный картой ключ невозможно забэкапить по определению. Для подключей это не проблема, потому что им не нужны резервные копии (кроме ключей шифрования). Но для ключа сертификации это означает, что пользователь должен сгенерировать ключ на хосте и скопировать его на карту, то есть хост должен обеспечить достаточную энтропию для генерации криптографически стойких случайных чисел, например. Также имейте в виду возможность сочетания разных подходов: например, вы можете использовать карту-ключ для повседневных операций, но хранить резервную копию ключа сертификации на LUKS-зашифрованном офлайновом томе.
Карты-ключи представляют собой новый элемент в цепочке доверия: вы должны доверять производителю устройства, что он не включил какой-нибудь вредоносный код в прошивку или аппаратное обеспечение. Вдобавок, вы должны верить в правильную реализацию. Карты-ключи сложнее обновлять: прошивка может быть преднамеренно закрыта для доступа с хоста по причинам безопасности или может требовать для манипуляций с ней специального программного обеспечения. Карты-ключи могут выполнять определённые операции медленнее, чем CPU, потому что там маленькие встроенные микроконтроллеры с ограниченной вычислительной мощностью.
Наконец, карты-ключи могут поощрять пользователей доверять свои секреты многим машинам, что противоречит принципу «минимального количества персональных данных». Полностью противоположный подход называется Trusted Physical Console (TPC): здесь вместо того, чтобы пытаться доставить секретный ключ на все машины, у вас есть единственная машина, которая используется для всех криптографических операций. В отличие от карты-ключа, TPC — это реальный компьютер, например, ноутбук, которому не требуются специальные процедуры для управления ключами. Недостаток, конечно, в том, что вам придётся везде носить с собой этот ноутбук, что может оказаться проблематичным, особенно в некоторых корпоративных окружениях, где запрещено приносить собственные компьютеры.
Краткие практические советы по картам-ключам
Записать ключи на карту достаточно просто:
- Начните с временного ключа для проверки процедуры:
export GNUPGHOME=$(mktemp -d)
gpg --generate-key - Отредактируйте ключ, использую идентификатор пользователя (UID):
gpg --edit-key UID - Используйте команду
keyдля выбора первого подключа, затем скопируйте его на карту (также можно использовать командуaddcardkeyпросто для генерации нового подключа прямо на карте):gpg> key 1
gpg> keytocard - Если хотите перенести подключ, примените команду
save, которая удалит локальную копию секретного ключа, так что единственная копия будет храниться на карте. В противном случае используйте командуquitдля сохранения ключа в связке, но храните секретный ключ в свой обычной связке ключей; ответ "n" на "Сохранить изменения?" и "y" на «выйти без сохранения?». Таким способом карта станет резервной копией вашего секретного ключа. - Если вы довольны результатом, повторите шаги с 1 по 4 со своей обычной связкой ключей (сброс
$GNUPGHOME)
После того как ключ перенесён на карту, команда --list-secret-keys покажет его как sec> (или ssb> для подключей) вместо обычного ключевого слова sec. Если ключ полностью отсутствует (например, если вы перенесли его в контейнер LUKS), то появится знак #. Если понадобится использовать ключ с резервной копии на карте, вы просто запускаете gpg --card-edit при подключенной карте, затем набираете в командной строке команду fetch, чтобы извлечь открытый ключ, который соответствует секретному ключу на карте (тот остаётся на карте). Та же самая процедура, как при использовании секретного ключа на другом компьютере.
Заключение
Существуют неформальные руководства по оптимальному использованию OpenPGP, и кое-где рекомендуют хранение ключей в офлайне, но там редко объясняют, что конкретно имеется в виду. Хранение основного секретного ключа в офлайне очень важно с учётом возможных рисков компрометации, и здесь мы рассмотрели основные способы такого хранения: на изолированной системе, в LUKS-зашифрованной связке ключей или с использованием карт-ключей. Каждый из этих способов имеет свои недостатки, но я рекомендую освоить работу с картами, если вы используете несколько компьютеров и хотите получить стандартный интерфейс с минимальными проблемами конфигурации.
И конечно эти подходы можно сочетать. Например, в этом руководстве используется карта-ключ на изолированном компьютере, что элегантно решает проблему, как передавать подписи с изолированного компьютера во внешний мир. Но это определённо способ не для слабонервных.
Если мы решили использовать карту-ключ, следующим шагом станет выбор конкретной модели. Об этом мы расскажем в следующей статье, где я изучу производительность, механическую конструкцию и другие факторы.
Автор: m1rko
