# Open Source FIDO-токены

Доклад: «Open Source FIDO-токены»
Спикер: Иван Зорин

## Вступление

Всем привет. Доклад будет и про open source, и не совсем про open source, про хакерное и не совсем хакерное. В общем, сейчас все увидите.

Название доклада на экране. Спасибо, что остались. Если вы меня слушаете, то я такой: нет времени объяснять, я не очень хорошо умею рассказывать про себя. Я предпочитаю, чтобы за меня говорили мои дела.

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

У меня есть план сегодняшнего выступления. Я постараюсь его придерживаться, но там как пойдет, потому что у меня на самом деле очень много тезисов, которые хотелось бы озвучить.

В начале, по традиции, дисклеймеры. Здесь не будет ноликов, здесь не будет единичек, и также здесь не будет LLM-ок. Один из предыдущих докладчиков говорил, что он не копайлит. Вот я не LLM-лю вообще, хотя, судя по панельной дискуссии, наверное, уже давно пора.

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

В контексте этого доклада токен — это физическое отдельное устройство для двухфакторной аутентификации.

## Зачем нужен отдельный токен

Из чего состоит такое устройство? Очевидно, из hardware и software. Но почему? Зачем нам нужно еще одно устройство?

Иван, вот смотри: мы и так обвешаны умными устройствами. У нас есть смартфоны, умные браслеты, чего только нет. Зачем мне еще одно устройство, тем более для двухфакторки, если у нас есть такие замечательные средства, как SMS и отдельные приложения?

Отдельные приложения для OTP, кстати, тоже есть open source. Я, например, рекомендую Aegis: он и open source, и достаточно богатый по фичам. Но это не реклама.

Так вот, у нас есть SMS. В чем проблема? Есть связь — есть SMS, есть OTP. Нет связи — нет SMS, нет OTP. Нет OTP — нет аутентификации.

То же самое с приложением на смартфоне. Смартфон может разрядиться, смартфон может не включиться по каким-то причинам, и авторизация говорит: «до свидания».

## Как работают токены

Если архитектурно, то примерно так. Тут сейчас, наверное, проснулись сетевики, потому что что-то новое и принципиальное придумать сложно. Слоеный пирог везде плюс-минус один, потому что байтики ходят по проводам и обратно.

Но все же как? Я люблю задавать себе вопросы: как, почему, зачем, как вы уже могли понять.

Если совсем упрощенно: пользователь, наслушавшись, что 2FA с отдельными токенами — это круто, пошел себе такой токен и купил. Что он должен сначала сделать? Сначала он должен на ресурсе, на который хочет ходить при помощи токена, зарегистрировать этот токен, чтобы ресурс знал: по такому токену теперь можно к нему ходить.

Дальше очень-очень упрощенно. Знакомые криптографы и хардкорные железячники меня за такое упрощение просто сожрут заживо, но это действительно очень упрощенно.

При посещении ресурса ресурс отправляет на токен challenge. На токене получается challenge, считается response и отправляется обратно на ресурс, где ресурс делает verify.

Что здесь очень важно подчеркнуть красным: ключ физически не покидает устройство. В этом вся задумка токена, в этом вся идея.

Но если ресурс не знает о ключе, как же он тогда делает verify? Тут на помощь приходит математическая криптография, которая позволяет при помощи хеш-функции однозначно идентифицировать, что это именно тот токен, не зная ключа.

Нет verify — fail. Есть verify — auth. В смысле auth — это не призыв [неразборчиво], а сокращение от authentication.

## YubiKey и открытые стандарты

Что по конкретным производителям? Тут смотря какой вендор, смотря какие модели.

Секундная рекламная пауза и суперигра: какой самый популярный вендор? Будете угадывать по буквам или назовете все слово целиком? Конечно же, YubiKey.

Кстати, у кого они есть? Поднимите руку, пожалуйста. Давайте интерактива добавим, не стесняйтесь.

Ага, понял. Только две руки, но здесь аудитория не очень большая. В смысле, аудитория большая. Извините, я очень нервничаю. Спасибо, что слушаете. Я когда тараторю, еще не такие коры могу выдавать.

YubiKey на рынке давно. В них реализовано чего только не реализовано: есть практически все современные стандарты аутентификации и авторизации. Да, за «авторизацию» меня тоже потом после доклада коллеги сожрут.

Они полностью проприетарны — как по аппаратной части, так и по программной. Но в чем здесь особенность: несмотря на то, что они проприетарны, под них и при помощи сторонних разработчиков, и самой компанией написана куча всякого софта. Некоторый этот софт может работать даже с ключами, которые не YubiKey.

Почему? Возвращаемся к моделям различных протоколов на различных уровнях. За счет того, что большинство протоколов и спецификаций сегодня открыты, мы можем делать, скажем так, drop-in replacement. Нам не нужно с нуля разрабатывать всю инфраструктуру под токен, если мы делаем токен согласно уже существующим спецификациям.

FIDO — это акроним альянса, FIDO Alliance, в который входят различные компании, курирующие открытые стандарты, документацию и API. Если вы хотите реализовать свой токен, вы можете сделать это относительно легко.

И тут мы переходим к теме open source и важности открытости не только в протоколах, но и в софте.

## Свободный софт и открытое железо

Что такое свободный софт идеологически? Это софт, который удовлетворяет четырем свободам: запускать программу, изучать ее, модифицировать и распространять измененную версию. Именно в исходных кодах.

А если перекладывать эти принципы на железо, как это может выглядеть?

Есть какое-то устройство, есть открытый дизайн, есть доступные схемы. Даже если отдельные узлы проприетарны — например, какие-то компоненты, микроконтроллеры, микропроцессоры, — сама схема и принцип открыты, а устройство поддерживается открытым софтом.

Один из моих любимых примеров — компания Inverse Path, которая сделала USB Armory. Это, по сути, Raspberry Pi в формате USB-флешки, но она полностью поддерживается всем тем, что есть в upstream. Вам даже не нужно возиться с патчами.

## Альтернативы, о которых не будет доклада

Доклад вроде как про токены и open source. Но сначала — то, о чем я говорить не буду.

Librem Key — это, по сути, ребренд. OnlyKey как проект закончился уже после того, как я о нем услышал.

Причем здесь Trezor и Ledger? Это отдельные аппаратные холодные криптокошельки, если кто не знает. Некоторые производители как дополнительную фичу добавляют на криптокошельки возможность OTP. Но поскольку это все-таки out of scope, а сами устройства изначально разработаны для другого, я про это говорить не буду.

Но что здесь еще важно упомянуть, особенно тем, кто интересуется платформенной программно-аппаратной безопасностью: очень настоятельно рекомендую ознакомиться с этим исследованием. Ребята поломали и Trezor, и Ledger, и что-то еще. Обратите внимание: Ledger надо вычеркнуть, потому что он proprietary.

Несмотря на то, что Trezor открытый и пытается быть максимально открытым криптокошельком, а Ledger закрытый, уязвимости нашли и там, и там. Я немного забегаю вперед, но потом еще поговорим, если будет время, о категории «безопасен ли open source».

## SoloKeys

Собственно, альтернативы, о которых я буду говорить, — вот эти ребята. Началось все с проекта, когда в январе 2016 года Conor Patrick выложил на GitHub схемы и инструкции, как собрать вот такой FIDO-токен.

Конечно, по сравнению с видом корпоративных YubiKey он выглядел не очень, но это было только начало. Он выложил это на GitHub, как я сказал. Вот примерная рассыпуха, которую нужно было накупить, чтобы это собрать, и вся плата выходила в 3 доллара. То есть на 300 баксов можно было собрать примерно 100 штук.

Позже Conor вместе со своими друзьями, коллегами и товарищами собрал группу. Они основали компанию, провели краудфандинг, собрали денег и где-то в 2018 году выпустили, как они заявляют — и, насколько мне известно, это так, — первые в мире open source FIDO-токены.

Тут то, про что я говорил: несмотря на то, что в качестве основного микроконтроллера используется проприетарный STM32, на него есть даташиты, но сама концепция этого микроконтроллера закрыта. Все, что было нужно, они открыли.

По software-стеку прошивка была написана на C, и там был очень прикольный Python tooling. Потом, если будет время и будет интересно, я объясню, в чем там прикол.

Они успешно это зарелизили, начали отправлять пользователям. Потом посмотрели и подумали: ну, конечно, все хорошо, но надо переделать. И пришли со второй ревизией в 2021 году.

Под вторую ревизию они тоже начали делать сборы по краудфандингу, но тут, как кто-то, может быть, помнит, в конце года пришел ковид, и это им подломило планы. Не столько ковид, сколько нарушение цепочек поставок и последовавший за этим чипогеддон.

Это была одна из причин, по которым они, к сожалению, на данный момент скорее мертвы, чем живы. Но, как вы знаете, птица Феникс, восставшая из пепла, дала толчок другому проекту. Я про него позже упомяну.

Под вторую ревизию они решили выкинуть весь software-стек, который был написан до этого. Взяли Rust: он тогда как раз становился модным, особенно из-за своих security-фич. На базе Rust они запилили свою собственную как бы proto-RTOS, назвали ее Trussed. И весь tooling у них, если я правильно помню, на Rust также написан.

Но эту историю мы пока отложим в сторону.

## OpenSK

Параллельно был основан проект OpenSK. OpenSK был от Google, и здесь ребята пошли немного другим путем.

Что делали SoloKeys? Они дизайнили железо с использованием известных компонентов, отправляли это на заводы, заводы делали устройства, отправляли обратно, они их прошивали.

Google пошел другим путем. Они подумали: вот смотрите, у нас сейчас чипогеддон разгорается, а давайте вместо того, чтобы что-то кастомное дизайнить, просто напишем софт под железо, которое общедоступно.

Они взяли nRF52840 — это широко известный в узких кругах чип от Nordic — и увидели, что у него есть dev kit. Конечно, такую dev board использовать для токена как-то не ок, но примерно та же dev board, просто немного более стройная, есть в формате USB-флешки. Они подумали: давайте будем делать именно под конкретную модель.

В процессе они даже сделали громкий анонс в своем блоге, выкатили проект у себя на GitHub. Но, как они добавили плашку, так она и висит: вроде бы Google, но не Google. Это все R&D, если что-то не так — сами виноваты.

И вишенкой на торте будет то, что nRF внутри себя, именно этот чип, реализует криптосопроцессор, который считает криптографическую математику очень-очень быстро. Но они до сих пор всю криптографию реализуют software-но. Почему? Пока до сих пор никак не добили.

OpenSK вышел в релиз в 2020 году на USB-девайсе от Nordic. Но еще до релиза OpenSK была компания Makerdiary из Шэньчжэня. Они тоже делали на базе nRF похожие платы для отладки, умного дома и прочего. Поскольку чип тот же, планировка практически та же, OpenSK достаточно быстро портировали и на их устройство.

В качестве software-стека используется Tock OS. Это другая free RTOS, написанная на Rust, тоже примерно под такие application-цели.

## Titan Security Key

По поводу Google, не знаю, стоит ли на этом останавливаться, но совсем быстро. Google, как и YubiKey, решил выйти на рынок ключиков и зарелизил уже две ревизии своих ключей, которые назвал Titan Security Key.

Если вы знаете, у Google есть своя линейка Pixel. В последних Pixel есть ARM-процессор, который называется Titan, и у этого процессора есть криптографический сопроцессор, который у них называется Titan M.

Так вот: Titan в Pixel, Titan Security-сопроцессор и Titan-ключ — это три разных Titan. Я не знаю, что там происходит в Google с неймингом. Видимо, они очень любят мифы Древней Греции. Зачем вам эта информация, я не знаю, но я хотел с вами ей поделиться.

## Nitrokey

И тут мы подходим к хедлайнеру моего рассказа. Это компания Nitrokey, которая начиналась еще в 2009 году. Естественно, когда никаких FIDO Alliance даже в проекте не было.

Они начинали с того, что тогда было модно и востребовано в бизнесе, а именно с различных смарт-карт. Поэтому у них очень богатый опыт.

Когда они увидели, что ребята из SoloKeys делают со второй ревизией, они к ним активно подключились. У них шел очень уникальный в мире свободного железа симбиоз: казалось бы, конкуренты делают один и тот же продукт. Вроде коммерческие компании, должны грызть друг другу глотки. Но в лучших традициях научно-промышленного сотрудничества они не просто не мешали друг другу, они активно сотрудничали.

Внимательные зрители могли заметить, что hardware там тот же самый. Почему? Потому что, когда выходил второй SoloKeys, в проекте уже был Nitrokey. Они, глядя на то, что делает SoloKeys, попытались в Nitrokey избежать всех ошибок, которые, к сожалению, оказались фатальными для SoloKeys. Даже Trussed — это их совместная разработка.

## Gnuk

Nitrokey — это, можно сказать, лайнер, а Gnuk — такой underdog. Сейчас вы поймете, почему я его сюда добавил.

Это не FIDO, это смарт-карта. Если кто помнит, в корпоративном секторе были очень популярны ThinkPad, у ThinkPad был отдельный слот под смарт-карты. Смарт-карта на ThinkPad — это не то, что делает Gnuk, совсем не то, но принцип примерно тот же.

Что позволял делать Gnuk? Gnuk позволял вам в дешевое устройство запихать GPG-ключи, чтобы потом подписывать ими электронную почту, и SSH-ключи, чтобы потом ходить на серверы.

Но все, наверное, знают эту картинку. Почему я ее сюда добавил? Смотрите, на чем запускается Gnuk. Возвращаемся к микроконтроллерам.

Есть микроконтроллер от STM, его я уже не раз упоминал. Чтобы отлаживать железо, software-ных способов отладки иногда недостаточно. Для этого нужен другой аппаратный отладчик, программатор. Чтобы удобно и комфортно отлаживать STM, нужен проприетарный, закрытый, дорогой SEGGER J-Link.

Восточные товарищи, естественно, быстро подсуетились и выпустили клон. Так вот, внимание, наберите воздуха в грудь: Gnuk — это проект, который запускается на клоне программатора для STM.

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

Почему? Потому что, во-первых, это дешево, во-вторых, это уже готово, и, в-третьих, возвращаемся к истории с OpenSK: зачем дизайнить свое железо, если можно просто задизайнить софт под железо, которое уже есть.

Бежит это все на стеке, написанном на C. PolarSSL — одна из библиотек, альтернатива OpenSSL.

## Безопасность, proprietary и open source

Тут, возможно, возникает вопрос: Иван, а что ты вообще такое несешь? Мы же на какой-то хардкор пришли посмотреть. Можно что-то посекьюрнее, побезопаснее, пожестче по железу?

Смотрите, входим в дебри программно-аппаратной безопасности. Есть такие термины, и уже относительно давно это отчасти применяется на больших обычных generic-компьютерах: например, в виде Secure Boot, в виде разных [неразборчиво], для обезопасивания процесса загрузки, firmware, целостности и прочего.

А как это можно применить к токенам? И причем здесь open source и безопасность?

Берем YubiKey. Как я говорил, они полностью проприетарные, полностью закрытые. Информация о том, что они запущены на чипах Infineon, получена не благодаря компании, а вопреки, благодаря усилиям независимых reverse-инженеров, которые чего только с этими YubiKey не делали.

И тут возникает ситуация классического принципа security through obscurity, который, как вам скажет любой начинающий криптограф, просто не работает. Он просто не работает.

К тому же у YubiKey с первых моделей прошивка не обновляемая. С одной стороны, вроде бы хорошо: тогда мы защищены от этих ужасных supply chain attacks, которые сейчас везде бахают. Но в чем проблема? Она не обновляемая, не считываемая и не записываемая.

Тот YubiKey, который к вам приедет, вы даже сами лично не сможете удостовериться, какая прошивка туда зашита. И если обнаружится серьезная уязвимость в программной части, все, что вы можете сделать, — выкинуть старый YubiKey и купить новый. Хотя, может быть, это часть бизнес-модели. Тут действует презумпция невиновности.

Исходя из предыдущих пунктов, такие проприетарные ключи совершенно не подлежат аудиту. Либо мы аудитируем их только методом черного ящика, пытаясь что-то оттуда как-то достать.

А, да, кстати, по поводу «достать». Помните, я говорил, что ключ неизвлекаем? Можете забыть. Ну как — не совсем. Сейчас объясню.

Хорошо, Иван, ты говоришь: секьюрно же, должно быть никаких уязвимостей, они же, наверное, все предусмотрели. Ну нет уже CVE-шек, да?

Больше на слайд не влезло. Спасибо, я старался. Естественно, здесь не все криты и не все нолики. По каждому из них — да, больше, чем доклады, я люблю метадоклады — по некоторым из них можно читать полутора-двухчасовые доклады.

Например, что такое ROCA Factorization Attack? Это атака, которая позволяет вытащить с YubiKey приватную часть RSA-ключа для нового 2048-битного RSA-ключа. Вам для этого потребуется, конечно, несколько денежек, где-то порядка 50-100 тысяч долларов, но я считаю, что это неплохо.

По уязвимости EUCLEAK был выпущен почти 100-страничный доклад от компании NinjaLab, который читается как computer science на грани научной фантастики.

Что ребята сделали, если совсем вкратце? Decap'нули чип, полностью его сняли, настроили кучу электромагнитных датчиков и потихоньку считывали оттуда. Да, естественно, это лабораторные условия, дорогое оборудование, где-то по 10-15 тысяч долларов.

Но цена атак на железо со временем снижается.

Раньше как было? Делаем переполнение буфера, никаких защит нет, все отлично. Потом появился ASLR. Появился ASLR — придумали ROP-цепочки. И так оно шло до тех пор, пока софт не стал относительно безопасным.

Когда закончились низковисящие фрукты в софте, что пошло дальше? Ребята начали ломать железо, а там оказался весь тот же процесс в миниатюре. То есть если какую-то железку еще не взломали, это не потому, что там нет уязвимости. Возможно, по этой железке исследователи просто еще не нашли какие-то более низковисящие фрукты.

## Чем помогает открытая прошивка

Как от этого защищаться? Тут на помощь приходят open source и свободные прошивки.

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

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

Опять же, мы возвращаемся к проблеме: даже если фикс сделан, вы не сможете прошить прошивку с фиксом на непрошиваемый токен.

И тут то, о чем я говорил в начале: безопасность proprietary и безопасность open source. На мой скромный взгляд, миф, что open source безопаснее. Но важно понимать практическую ценность open source.

Что происходит при vulnerability management, когда вы обнаружили какую-то критическую багу? Точнее, даже не вы, а производитель или исследователь у производителя. У вас только один выход: ждать, когда сам производитель починит, сделает фикс, выкатит апдейт и вы его установите.

В случае с open source vulnerability management существенно сокращается и упрощается. Вы, не дожидаясь производителя, если у вас вся цепочка поставок софта и прошивок под вашим контролем, просто берете фикс, накатываете, и ваши волосы мягкие и шелковистые.

## Почему open source важен

Тут, может быть, немного романтизма, но я люблю свободное ПО за то, что без него меня бы здесь не было. Потому что это наследие, образование и даже бизнес-возможности, как мы видим по проектам SoloKeys и Nitrokey.

Что касается наследия: если бы SoloKeys были закрытыми и проприетарными, то Nitrokey, возможно, даже не случился бы.

Если завтра по каким-то причинам Yubico, сама контора и все разработчики просто уйдут в отпуск, уйдут в леса, сделают дауншифтинг, как сейчас удобно, вы останетесь один на один со своими необновляемыми и непропатченными проприетарными устройствами.

В случае с open source, как показывает пример SoloKeys и Nitrokey, даже если одна компания загибается, если проект действительно нужный и важный, и другие пользователи готовы вкладываться в него даже финансово, рано или поздно такой проект будет подхвачен и продолжен.

С точки зрения образования: я вижу здесь много молодых лиц. Как человек, который сам был студентом, я просто не понимаю, как можно учиться системной инженерии на proprietary. Да, у меня самого есть знакомые, которым hex и asm читать проще, чем исходники. Я не шучу, это не анекдот. Они могут ковыряться целый час в коде, потом его скомпилить и за минуту найти то, что им нужно.

Но все равно именно открытость исходников, открытость стандартов и открытость проектов нас здесь сегодня собрала. Я так считаю.

## Как мог бы выглядеть идеальный процесс

Если говорить о применении этого к программно-аппаратной безопасности, то, уже закругляясь: Иван, а если бы тебе дали неограниченное количество денег и неограниченное количество времени, чем бы ты занялся?

Одна из задач и идей — как бы я строил процесс запрашивания современных программно-аппаратных комплексов.

Во-первых, когда вы покупаете устройство, я думаю: а что, если оно к вам вообще будет приходить чистым? Даже если там есть какой-то flash, какой-то storage, там будут нули, и вы сможете это верифицировать.

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

Генерируем свои ключи, подписываем прошивку, прошиваем. И при этом периодически, возвращаясь к пункту 0, смотрим, что прошивка, которую мы зашили, не поменялась. Да, там будут не нули, там будет binary, но важно, что этот binary не мутировал с момента последнего использования.

Самое интересное, что частично это уже так или иначе сделано. Где-то меньше, где-то больше. Это есть в trusted boot-решениях, secure boot-решениях, attested boot и прочих boot. До токенов это пока не добралось, но я считаю, что это, возможно, следующий логичный шаг.

А как это все делать на практике — это уже совсем другая история.

Спасибо, что выслушали.

## Дополнение про аудит

Самое важное по поводу открытости компонентов: невозможно проаудировать то, что нельзя проаудировать.

В случае с proprietary я не могу взять устройство, с которого даже flash не сдампить, отнести его независимому вендору и сказать: дорогой мой друг, проаудируй, пожалуйста. Он полгода будет собирать лабораторию за 10 тысяч долларов просто чтобы понять, что там вообще за чип, как это правильно растворить в кислоте, чтобы маркировка не потерялась, если она там еще осталась.

А в случае с открытыми свободными решениями, которые публично доступны, все иначе. Даже если у нас есть аудит от самого производителя — например, вендор говорит: «Вот наш продукт, мы показали его таким-то ребятам. Полный репорт мы вам не покажем, но они нашли такие-то CVE», — в случае с open source это все прозрачно.

Даже если вы не доверяете одному аудитору, вы всегда можете взять схемы, даташиты, исходники и отнести другому вендору, и он вам это все проаудирует.

SoloKeys и Nitrokey занимались и занимаются именно этим: периодически в полностью открытом режиме показывают исходники компаниям, платят другим компаниям, чтобы те посмотрели, что у них все secure. Если что-то не secure, они моментально это фиксят, патчат, заливают фиксы в прошивку и публикуют публичные отчеты.

Спасибо, надеюсь, не утомил.

## Вопросы и ответы

Вопрос из зала: Спасибо за доклад. Два неудобных вопроса. Вопрос первый: то есть, если собрать закладки, вы предлагаете использовать чипы без защиты в пользу чипов, которые не обеспечивают никакой защиты от вытаскивания ключей. Я правильно понял, что это закладки?

Ответ: Нет, не совсем. Смотрите, в чем прикол: одно не противоречит другому, как бы парадоксально это ни звучало. Ключи пусть будут приватные.

Ой, блин, у меня столько историй. Сейчас сначала на вопрос отвечу.

Одно не противоречит другому. Почему? У YubiKey, помимо варианта для рядовых пользователей, есть FIPS-сертифицированные ключи. Это отдельная линейка.

Что такое FIPS? Это североамериканский стандарт: если ты хочешь всю эту PKI- и токенную инфраструктуру поднимать в госухе, ты должен пройти FIPS. YubiKey этот FIPS прошли.

Но даже в FIPS нет обязательного требования на несчитываемость или неперезаписываемость прошивки. Вот как. Даже в FIPS понимают, что security through obscurity — это не выход. Секретом, возвращаясь к Брюсу Шнайеру, должен быть только ключ.

Как этот ключ зашивается в secure element или не в secure element — это уже вопрос архитектуры. Прошивка, в принципе, может быть считываемой и обновляемой, но при этом ключ в теории может быть неизвлекаемым. Вот такие системы нужно строить. Надеюсь, я ответил на ваш вопрос.

Вопрос из зала: Да, отлично. Второй вопрос будет еще более неудобный. Как простому обывателю без лаборатории за 10-50 тысяч долларов проверить, что прошивка, которую записывали на устройство, действительно окажется этой прошивкой? Как мы доказываем себе, используя наш ключ, что на оборудовании не осталось программного хода, который позволит в дальнейшем модифицировать возвращаемые данные?

Ответ: То есть суть неперезаписываемой прошивки в том, что если устройство скомпрометировано, то лучше его уничтожить. Это снова вопрос цепочки поставок. Если отвечать на хвостик вашего комментария, а если отвечать на начало, то да, это Trust Issues и Zero Trust: никому нельзя верить, мне можно.

Тут я с вами полностью согласен: у меня ответа нет. Понимаете, я люблю такие доклады, когда в конце зрители уходят не с ответами, а с еще большим количеством вопросов. Я считаю, что это на самом деле офигенно.

Тут можно только кулуарно думать и обсуждать, как верифицировать полностью открыто.

А, вот еще что забыл сказать. Есть широко известный в узких кругах Bunnie Huang. У него был Precursor — проект смартфона, который вы покупаете, он к вам приходит, и вы можете в домашних условиях вплоть до железа верифицировать, что там железо именно то, что декларируется.

Смотрю, вы шарите, наверное, знаете про этот проект? Человек кивает.

Вопрос в ресурсах, цене и грамотной архитектуре. Это не «все плохо, все пропало». Я сам критик по жизни, саркастичный и очень токсичный, но люблю думать конструктивно. Я даже не столько реверсер: если что-то ломаю, то ломаю с целью понять, как от этого потом защититься. Вот это самое «how to defend» я с удовольствием слушаю.

Спасибо организаторам за время и за такой клевый митап. Извините, что я тут как с ноги влез со своим железом, но в одном мероприятии сказано было: PR, прикол, bottom, пайка, канифоль, схемы, прошивки — да пожалуйста.

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

Ответ: Это очень хороший вопрос. У меня на него нет ответа. Он частично перекликается с тем, что мы обсуждали в рамках предыдущих вопросов. Zero Trust во все поля. Как-то надо строить, надо думать, надо собираться.

Здесь много молодых людей. Может быть, кто-то из них в будущем что-то такое накреативит. У меня нет ответа. Но вы понимаете, что это фундаментальный вопрос computer science и информационной безопасности. Фундаментальный.

Вопрос из зала: В принципе, в open source сейчас обсуждается такой вызов: из-за того, что модели на критике находят очень большое количество уязвимостей в ПО, использовать ПО в бизнесе стало сложнее. Почему? Потому что enterprise-версия ПО, скорее всего, будет патчиться разработчиками довольно оперативно, а open source, скорее всего, будет патчиться очень нерегулярно. Например, Nginx или Kubernetes. Как вы думаете, такой риск есть? Как с ним бороться? Люди, которые делают open source локально, что ими движет?

Ответ: Смотрите, я, наверное, очень быстро говорил. Даже если сами maintainers open source не чешутся при исправлении какой-то уязвимости, ничто не мешает вам самому — либо найти кого-то, кто сделает это быстрее, чем официальный maintainer, — протащить такой фикс в инфраструктуру и залатать дырки.

В случае с proprietary вы просто будете ждать вендора, когда он почешется.

Комментарий из зала: Тут управляемый риск, что вам, возможно, придется делать это каждую неделю, как с обновлениями. То есть вы будете каждую неделю поднимать инфраструктуру, чтобы убить technical debt и фиксить. Вот такой риск.

Ответ: Это day-to-day management. Я тут просто не вижу разницы с proprietary. Может быть, я вопрос не понимаю.

Комментарий из зала: Proprietary может позволить себе выделенного разработчика, который будет патчить каждую неделю продукт. А open source...

Ответ: Есть и open source. Тут у нас уже начинается небольшой холивар.

Были случаи... Вот есть, например, Google Project Zero. Кто знает, это security-команда внутри Google. Она раскапывает нолики. Как минимум два раза они нарушали 90-дневное эмбарго, зарелизив информацию о баге, который еще не был починен Microsoft, потому что у Microsoft не было на это времени и средств. Google решил, что в целях того, чтобы поторопить Microsoft, они это релизят.

А вы мне говорите, что у proprietary есть возможность каждый день выпускать hotfixes. Это немного противоречит одно другому.

У меня обратный вопрос. Допустим, у вас почтовый сервер и программное обеспечение электронного документооборота из реестра отечественного программного обеспечения. Честный ответ, пожалуйста: зависит от задачи. Просто для патча: кто быстрее патчит? В зависимости от вендора. Может быть адекватный вендор, который будет [неразборчиво] с теми, кто коммитится к виду.

Я тоже люблю FOSS. Просто есть факт, когда люди из Tails взяли и выпилили к чертям этот Thunderbird, когда появился [неразборчиво]. Еще есть агенты, они тоже умеют почту.

Спасибо огромное. Спасибо.

## Неоднозначные места

- В самом начале перед приветствием в сыром транскрипте есть фраза «Поэтому мы не можем противимо». Она выглядит как хвост предыдущего выступления или ASR-мусор и в основной текст не включена.
- «Здесь не будет лалаймок» отредактировано как «LLM-ок», но точная шутка могла звучать иначе.
- Шутка «auth — это не призыв [неразборчиво]» распознана плохо; смысл про сокращение authentication сохранен.
- Список проектов на слайде «о чем я говорить не буду» восстановлен частично: Librem Key, OnlyKey, Trezor, Ledger. В транскрипте есть неясный фрагмент «не траке, про нетраке будет дальше».
- У SoloKeys год выпуска исправлен на 2018 по контексту проекта; в ASR было «2008», что явно противоречит хронологии FIDO-токенов.
- «Trussed» восстановлено по контексту SoloKeys/Nitrokey; в сыром тексте звучит как «трасса».
- Фрагмент про Nitrokey: «внимательные зрители могли заметить, что hardware там тот же самый» восстановлен по смыслу; конкретная подпись на слайде могла уточнять модель или плату.
- Блок про Secure Boot содержит неразборчивое слово после «в виде разных...». Термин не восстановлен уверенно.
- «EUCLEAK» восстановлено по контексту NinjaLab и атаки на аппаратные токены; в ASR было «Euclid».
- «how to defend» восстановлено по смыслу из фразы «ломаю, чтобы понять, как защититься»; исходная английская формулировка в записи нечеткая.
- В финальной дискуссии о FOSS/proprietary есть несколько сильно неразборчивых реплик из зала, особенно про «реестр отечественного ПО», «Tails», «Thunderbird» и «агенты». Они оставлены в укрупненном виде с пометками.