Доклад Ивана Зорина «Open Source FIDO-токены» начинается не с битов, схем и CVE, а с уточнения словаря. В этом разговоре «крипта» — это прежде всего криптография, а «токен» — не биржевой актив и не «топливо» для агентов при вайб-кодинге или решении очередного CTF-таска, а отдельное физическое устройство для двухфакторной или многофакторной аутентификации. Тот самый аппаратный токен, который лежит отдельно от ноутбука или смартфона и участвует в аутентификации именно как независимый фактор.
Главная линия доклада — не «open source безопаснее proprietary». Иван как раз осторожен с таким тезисом. Его позиция тоньше: открытость сама по себе не отменяет уязвимости, не заменяет архитектуру и не делает железо магически надёжным. Но она меняет практику доверия. Она позволяет изучать, пересобирать, проверять, чинить, передавать проект дальше и строить вокруг него культуру, в которой устройство не является чёрным ящиком.
Зачем нужен отдельный FIDO-токен
На первый взгляд отдельный FIDO-токен выглядит избыточным. У пользователя уже есть смартфон, приложения для OTP/TOTP, SMS, иногда умные часы и целая россыпь устройств, которые можно привязать к аккаунту. Зачем носить ещё одну маленькую железку?
Ответ начинается с отказоустойчивости и разделения ролей. SMS зависит от связи: нет сети — нет SMS, нет OTP, нет входа. Приложение-аутентификатор зависит от смартфона: телефон разрядился, сломался или не включился — и второй фактор исчезает вместе с ним. При этом хорошие open source-приложения для OTP существуют; Иван отдельно упоминает Aegis как пример функционального и открытого решения. Но это всё равно программа на многофункциональном устройстве.
Аппаратный токен устроен иначе. Его задача уже, поверхность меньше, а смысл именно в отдельности. Он не должен быть универсальным компьютером в кармане. Он должен хранить секретный материал и участвовать в аутентификации так, чтобы этот секрет не превращался в файл, который можно скопировать, синхронизировать, украсть из бэкапа или вытащить из скомпрометированной операционной системы.
Именно поэтому отдельный токен в 2FA/MFA — не фетиш железа ради железа. Это попытка вынести критическую часть аутентификации в устройство, которое можно физически контролировать, потерять отдельно, заменить отдельно и проектировать с одной главной функцией.
Challenge-response: ключ не покидает устройство
В докладе модель работы токена намеренно описана упрощенно, но это полезное упрощение. Сначала пользователь регистрирует токен на ресурсе: сервис должен узнать, что теперь с этим аккаунтом связан конкретный аппаратный фактор. После этого при попытке входа ресурс отправляет токену challenge. Токен вычисляет response и возвращает его сервису. Сервис выполняет verify: если проверка прошла, аутентификация успешна; если нет, вход не состоялся.
Ключевой принцип здесь можно написать красным: key never leaves device. Секретный ключ физически не должен покидать токен. Наружу уходит не сам ключ, а результат операции над challenge. В этом и состоит практический смысл схемы challenge-response: сервис может убедиться, что перед ним правильное устройство, не получая секрет целиком.
Иван формулирует это как центральную идею токена. Пользователь не «вводит» второй фактор в привычном смысле, не перепечатывает код и не передаёт серверу секрет. Устройство отвечает на криптографический вызов. Если всё спроектировано правильно, компрометация канала или клиентского компьютера не должна автоматически означать утечку приватного ключевого материала.
Отсюда же появляется важный вопрос доверия к реализации. Если ключ «никогда не покидает устройство», то кто и как может подтвердить, что firmware действительно работает именно так? Что в нем нет ошибки, закладки, опасной библиотеки или неожиданного поведения? Здесь техническая тема почти сразу становится идеологической.
YubiKey, Yubico и сила открытых стандартов
Самый узнаваемый коммерческий образ аппаратного токена — YubiKey от Yubico. В докладе YubiKey описан как зрелый и популярный продукт, в котором реализовано множество современных механизмов аутентификации и авторизации. Но одновременно это пример полностью proprietary-подхода: закрыта и аппаратная часть, и программная.
При этом YubiKey существует не в вакууме. Вокруг него написано много софта, часть которого создана самой компанией, часть — сторонними разработчиками. Некоторые инструменты могут работать не только с YubiKey, потому что критична не магия конкретного вендора, а открытые протоколы и спецификации.
Здесь в докладе появляется FIDO Alliance: объединение компаний, которое курирует открытые стандарты, документацию, API и библиотеки для этой области. Благодаря открытым спецификациям можно делать совместимые устройства и drop-in replacement: не изобретать всю инфраструктуру заново, а реализовать токен так, чтобы он говорил на понятном сервисам языке.
Это важный поворот. Даже proprietary-устройство выигрывает от открытых стандартов. Но открытый стандарт — ещё не открытый продукт. Спецификация может быть публичной, а конкретная прошивка, микроконтроллерная архитектура, цепочка сборки и производственный процесс — закрытыми. Доклад как раз проводит границу между совместимостью с открытым API и настоящей проверяемостью устройства.
Free software, four freedoms и открытое железо
Чтобы объяснить open source-позицию, Иван возвращается к классике free software. Свободный софт — это не просто «код лежит на GitHub». Это четыре свободы: запускать программу, изучать её, модифицировать и распространять измененную версию. Существенно, что речь идёт об исходных кодах, а не только о бинарнике.
С железом сложнее, потому что физическое устройство нельзя свести к репозиторию. Но принципы можно перенести. Open hardware означает, что у устройства есть открытый дизайн, доступные схемы, понятный состав компонентов, документация и открытая программная часть. Даже если отдельные узлы остаются proprietary — например, микроконтроллер или отдельный криптографический компонент, — пользователь и независимый аудитор хотя бы видят архитектуру и могут обсуждать её предметно.
В этом месте доклад сближается с right to repair и hackerspace culture. Открытое железо — это не только про безопасность в узком смысле. Это про возможность учиться, чинить, повторять, портировать, собирать собственные устройства, проверять чужие решения и продолжать проект, если исходная компания исчезла. Для аудитории security/open-source/hardware это не романтическое приложение к теме, а часть инженерной устойчивости.
Один из любимых примеров Ивана вне FIDO-темы — USB Armory от Inverse Path: устройство в формате USB-флешки, поддержанное upstream-экосистемой. Смысл примера в том, что открытость становится особенно ценной, когда устройство не требует вечной зависимости от единственного производителя и набора закрытых патчей.
Open source FIDO tokens: SoloKeys, OpenSK, Nitrokey
Когда разговор переходит к альтернативам YubiKey, первым крупным примером становится SoloKeys. История начинается с проекта Conor Patrick: в 2016 году он выложил на GitHub схемы и инструкции, по которым можно было собрать FIDO-токен. Ранний вариант выглядел не как отполированный корпоративный продукт, но он показывал главное: аппаратный токен можно обсуждать, собирать и развивать открыто.
Позже вокруг проекта сложилась команда, появился краудфандинг, и в 2018 году, по словам доклада, SoloKeys выпустили первые в мире open source FIDO-токены. Важная деталь: даже в таком проекте не всё идеально открыто до транзистора. Основной микроконтроллер STM32 остаётся proprietary-компонентом, но схемы, прошивка и tooling были открыты настолько, насколько это было практически возможно в рамках проекта.
Первая версия прошивки была написана на C, с Python tooling. Во второй ревизии проект резко перестроился: команда перешла на Rust, а совместно с Nitrokey появилась proto-RTOS Trussed. В докладе Trussed звучит как пример того, как open source-проект в железе может порождать не только один конкретный продукт, но и переиспользуемую программную платформу.
OpenSK от Google идёт другим путем. Вместо проектирования собственного железа проект ориентируется на доступную платформу, в частности на nRF52840 и USB-устройства на его основе. Логика здесь близка к hackerspace-подходу: если подходящее железо уже массово существует, можно сосредоточиться на firmware и портировании. При этом Иван отмечает важную странность: у выбранного чипа есть криптографический сопроцессор, но криптография в OpenSK, по словам доклада, долго оставалась реализованной программно.
Nitrokey в этой истории выступает как более зрелый участник. Компания начинала ещё в эпоху смарт-карт, задолго до FIDO Alliance, и накопила опыт в аппаратной аутентификации. В докладе особенно важен не только сам Nitrokey, а его сотрудничество с SoloKeys. Формально это могли бы быть конкуренты, но в open hardware-мире они оказались участниками общей работы: смотрели на ошибки друг друга, развивали общий стек и фактически показывали, как свободный проект может пережить кризис одного производителя.
Есть и пограничные примеры. Gnuk — не FIDO, а смарт-карта, позволяющая хранить GPG- и SSH-ключи на дешёвом устройстве. Иван включает его в доклад не как прямую альтернативу FIDO-токену, а как иллюстрацию подхода: иногда практический смысл открытости в том, чтобы запустить нужный софт на уже существующем и доступном железе, даже если это клон программатора для STM.
Proprietary vs open source: безопасность и аудит
Самый опасный вывод из такого доклада звучал бы так: proprietary плохо, open source безопасно. Иван как раз от него уходит. Open source не гарантирует безопасность. Уязвимости находят и в открытых проектах, и в закрытых продуктах. В докладе отдельно упоминаются Trezor и Ledger в контексте исследований аппаратных криптокошельков: открытость одного и закрытость другого сами по себе не отменяют возможность атак.
Но различие проявляется в аудите и vulnerability management. Proprietary-устройство часто доступно исследователю только как чёрный ящик. Если нельзя считать firmware, нельзя посмотреть исходники, нельзя проверить цепочку сборки и нельзя обновить прошивку, аудит превращается в дорогой reverse engineering: лаборатория, decap чипа, электромагнитные измерения, попытки понять даже то, что именно находится внутри.
В случае YubiKey Иван отдельно подчёркивает несколько проблем. Информация о чипах Infineon, по его словам, стала известна не благодаря открытости производителя, а благодаря независимым reverse-инженерам. Прошивка у ранних и актуальных в докладе моделей описывается как необновляемая, несчитываемая и незаписываемая пользователем. Это может выглядеть как защита от supply chain attacks, но у такой защиты есть обратная сторона: если серьёзная уязвимость обнаружена, пользователь не может самостоятельно установить исправленную прошивку. Ему остаётся заменить устройство.
Именно здесь тезис «key never leaves device» становится менее абсолютным. В нормальной модели ключ не должен покидать токен. Но аппаратные атаки существуют. В докладе упоминаются ROCA Factorization Attack и EUCLEAK. EUCLEAK описан как дорогое лабораторное исследование уровня decap, датчиков и сложного анализа. Это не бытовая атака, но Иван делает важное инженерное замечание: цена атак на железо со временем снижается.
Поэтому security through obscurity не может быть единственной стратегией. Секретом должен быть ключ, а не вся архитектура, не вся прошивка и не сам факт того, какой чип стоит внутри устройства. Закрытость может повышать стоимость исследования, но она же мешает независимой проверке и нормальному ремонту доверия после найденной ошибки.
Чем практически помогает открытая прошивка
Практическая ценность open source проявляется не в лозунге «все видят код, значит всё хорошо», а в возможности действовать. Если прошивка собирается из известных исходников, появляется шанс верифицировать не только текст программы, но и бинарный образ. Если инструментальная цепочка и набор утилит тоже контролируемы, можно обсуждать воспроизводимость сборки и прозрачность цепочки поставок.
В proprietary-модели при критической уязвимости пользователь зависит от производителя. Нужно ждать, пока вендор признает проблему, подготовит фикс, выпустит обновление и даст способ его установить. Если устройство непрошиваемое, даже выпущенный фикс может не помочь конкретному экземпляру.
В open source-модели цепочка короче. Если проект действительно открыт, исправление может подготовить не только исходный производитель, но и сообщество, независимый подрядчик или команда пользователя. Это не отменяет затрат: кто-то должен уметь читать код, собирать firmware, тестировать изменения и управлять риском обновлений. Но появляется управляемость. Пользователь или организация не заперты в ожидании единственного вендора.
Для аппаратных токенов это особенно важно, потому что устройство маленькое, но роль у него большая. Ошибка в такой железке может затрагивать доступ к почте, инфраструктуре, административным панелям, SSH, корпоративным ресурсам. И если аутентификация завязана на физический фактор, вопрос обновления и аудита становится не дополнительной опцией, а частью жизненного цикла безопасности.
Открытость как наследование, образование и бизнес
Одна из самых сильных частей доклада — разговор о том, зачем свободное ПО и открытое железо нужны помимо немедленной безопасности. Иван говорит о наследии, образовании и бизнес-возможностях.
Наследие видно на примере SoloKeys и Nitrokey. Если бы SoloKeys был полностью закрытым продуктом одной компании, его кризис мог бы означать конец линии. Но открытый код, открытые схемы и общая разработка Trussed позволяют другим участникам продолжать работу. В proprietary-мире исчезновение вендора оставляет пользователя с устройством, которое нельзя ни проверить, ни обновить, ни нормально развивать.
Образовательный смысл ещё проще. Невозможно нормально учиться системной инженерии, аппаратной безопасности и разработке прошивок только на закрытых продуктах. Да, reverse engineering важен, и есть специалисты, которым hex и asm порой удобнее исходников. Но массовая инженерная школа строится там, где можно открыть схему, прочитать код, пересобрать прошивку, ошибиться, исправить и понять, почему устройство ведёт себя именно так.
Бизнес-смысл тоже не исчезает. Open source не равен отсутствию коммерции. SoloKeys и Nitrokey в докладе показаны как примеры того, что вокруг открытого проекта можно собирать деньги, выпускать устройства, платить за аудит и строить продукт. Разница в том, что бизнес не обязан держаться на полной закрытости устройства от собственных пользователей.
Как мог бы выглядеть более доверяемый процесс
В финале Иван набрасывает почти утопическую, но инженерно понятную модель. Устройство приходит пользователю чистым: flash или storage заполнены нулями, и это можно проверить. Пользователь берёт верифицированные исходники прошивки, собирает их проверяемой инструментальной цепочкой, генерирует свои ключи, подписывает прошивку и прошивает устройство. Затем периодически проверяет, что записанный бинарный образ не изменился с последнего доверенного состояния.
Части этой логики уже существуют в trusted boot, secure boot и attested boot-подходах, но до маленьких аппаратных токенов, по словам доклада, такая практика пока не добралась в полной мере. И здесь появляется честная граница: открытость не решает весь trust problem. Как обычному пользователю без лаборатории доказать, что на устройстве нет скрытого механизма? Как проверить цепочку от чипа до компилятора? Где проходит разумный предел Zero Trust?
На эти вопросы в Q&A Иван не выдаёт готового рецепта. И это, пожалуй, правильно. Слишком простые ответы в аппаратной безопасности обычно подозрительны. Зато доклад предлагает направление: секретным должен быть ключ, а не вся система вокруг него; аудит должен быть возможен; прошивка должна быть проверяема; обновление не должно быть привилегией одного вендора; железо должно быть предметом изучения, ремонта и продолжения.
Выводы
Open Source FIDO tokens — это не обещание идеальной безопасности. Это разговор о том, кому принадлежит контроль над устройством, которое охраняет доступ к цифровой жизни и инфраструктуре.
Отдельный FIDO-токен нужен не потому, что SMS, OTP/TOTP или Aegis «плохие», а потому что аппаратный второй фактор решает другую задачу: хранит секрет отдельно и отвечает на challenge-response так, чтобы key never leaves device. Открытые стандарты FIDO Alliance делают совместимость возможной, но совместимость не равна проверяемости. YubiKey/Yubico показывает силу зрелого proprietary-продукта и одновременно предел доверия к закрытой аппаратно-программной платформе.
Open source и open hardware не отменяют уязвимости, не спасают от плохой архитектуры и не гарантируют, что железо невозможно атаковать. Но они дают другое: аудитируемость, возможность независимого исправления, право продолжать проект, образовательную ценность и культуру, близкую к right to repair и hackerspace culture. В области аппаратных токенов это особенно важно, потому что маленькое устройство становится точкой, через которую проходит большое доверие.
И в этом месте доклад про FIDO почти сам передаёт эстафету следующему разговору — о сообществах. Открытость работает не абстрактно, а через людей: тех, кто пишет код и схемы, проверяет чужие решения, чинит, спорит, приносит доклады, зовёт других, собирает конференции и помогает проектам жить дольше одного вендора, одного репозитория или одного вечера. Ну ёPRST.