Сталкиваясь с потребностью в скрытом сервисе I2P, большинство вынуждено пользоваться услугами хостинг-провайдеров. Например, потому что нет возможности обеспечить хороший аптайм ресурса на домашнем компьютере. Использование услуг дата-центра подразумевает доверие: мы надеемся, что персонал не будет злоупотреблять своим положением и кто-то не попытается украсть данные с дисков.
Увы, одной уверенности в серьезном проекте мало, потому что никогда нельзя исключить даже банальный взлом системы извне. Абсолютной безопасности не бывает, однако после любого инцидента вы наверняка хотите восстановиться максимально быстро. Этот мануал расскажет, как использовать временные ключи, чтобы адрес вашего скрытого ресурса не могли украсть даже в случае компрометации сервера.
Образование внутрисетевого адреса I2P
Создавая серверный туннель, который выводит локальный сервис в скрытую сеть, необходимо указать файл с ключами (если указывается несуществующий – создается новый файл со случайными ключами).
Файл с ключами содержит криптографические идентификаторы. Всего 391 байт публичной информации и секретные ключи, которые не публикуются. Хеш от блока публичной информации, содержащейся в файле с ключами, образует внутрисетевой адрес.
К полному адресу (391 байт публичной информации) осуществляется привязка как длинных адресов «.b32.i2p», так и коротких доменных имен в зоне «.i2p», поэтому заданный файл с ключами является критически важным: потеряв его, мы теряем и контроль над адресом. Если злоумышленник развернет с нашим ключом другой серверный туннель, работа изначального скрытого сервиса будет в лучшем случае нарушена, а в худшем – злоумышленник сможет выдавать свой ресурс за оригинальный для части пользователей, чей роутер найдет его лизсет первым.
Лизсеты
Серверные конечные точки, то есть скрытые сервисы сети I2P, публикуют информацию о себе на флудфилах, чтобы другие участники сети могли найти их. Эта информация называется лизсетом и включает в себя полный набор криптографических идентификаторов – полный адрес (391 байт), а также информацию о входящих туннелях. Поиск лизсета происходит по доменному имени, образованному от ключей. Если флудфил располагает нужным лизсетом, клиент получает информацию для связи с конечной точкой.
Безопасное хранение ключей
I2P имеет концепцию оффлайн-ключей (offline keys), которая позволяет хранить постоянные ключи в надежном месте. Другими словами, основной ключ хранится в безопасном месте, а на сервере используется временный, срок действия которого истекает через заданное количество дней. В случае его компрометации, спустя заданный срок действия, вы с полной уверенностью можете утверждать, что ваш сетевой адрес снова принадлежит только вам.
Данная возможность реализуется ключом подписи. Основной публичный ключ входит в массив полного адреса и непосредственно участвует в образовании внутрисетевого домена. При использовании функции оффлайн-ключей создается временный ключ подписи, который подписывается основным ключом. В публикуемом лизсете серверной конечной точки, использующей временный ключ, присутствует специальный флаг. Пользователь, получивший такой лизсет, проверяет основным ключом подписи конечной точки достоверность временного ключа, который также приложен к лизсету. Если подпись в норме, устанавливается стандартная сессия, в рамках которой временному ключу оказывается такое же доверие, как и основному, входящему в полный адрес конечной точки.
Инструмент для создания временных ключей присутствует в наборе i2pd-tools. Утилита называется offlinekeys и имеет следующий порядок принимаемых параметров: <output file> <keys file> <signature type> <days>. Последние два параметра можно опустить, указав только выходной файл и существующие ключи.
Без явного указания типа подписи, по умолчанию используется ED25519-SHA512 (кодовое обозначение 7), а срок годности равен 365 дням, то есть году. Тип подписи можно указать как в кодовом варианте, так и словом.
После того, как файл с временными ключами создан, его можно выгрузить на сервер и использовать в привычном виде. Главное – не забыть обновить ключи вовремя. Также можно написать скрипт, автоматизирующий процесс обновления ключей на удаленном сервере.
