Apple выпустила защиту SSH-ключей через Secure Enclave, но интерфейс получился уродливым

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

YubiKeys были единственным решением, отвечающим этим требованиям, поэтому я выбрал их. Я использую их последние десять лет или около того, и я очень доволен этим решением. См. https://github.com/drduh/YubiKey-Guide — там описано, как заставить ваши RSA-ключи, хранящиеся на YubiKeys, работать одновременно с GPG и SSH.

Одна фундаментальная проблема агентной разработки заключается в том, что доступ к ключу Secure Enclave требует присутствия человека. Если вы работаете без головы и не вошли в систему, Secretive (не уверен насчёт других) не сможет получить доступ к анклаву, даже если вы выбрали только "notify", а не "touchid".

Вот почему я скептически отношусь к тому, что этот подход может надёжно масштабироваться, хотя сегодня я полагаюсь на него. (Да, PATs решили бы эту проблему, но модель анклава — это то, что я пытаюсь сохранить пока что.) Вместо этого я написал небольшой демон, который настраивает сокет аутентификации SSH и выполняет переадресацию агента. Это работает, когда я путешествую с ноутбуком... но пока не с моего мобильного телефона.

Пример:

Ноутбук Удалённый Mac

┌─────────────────────┐ ┌──────────────────────────┐

│ Secretive │ │ ssh / git commit -S │

│ (Secure Enclave) │ │ │ │

│ ▲ │ ForwardAgent │ ▼ │

│ └── ssh ─────┼─────────────────►│ ~/.ssh/agent.sock │

│ │ │ (стабильный прокси) │

└─────────────────────┘ │ │ │ │

│ ▼ ▼ │

│ переадресованный локальный │

│ ноутбук Secretive │ […]

Статья начинается с неверной предпосылки.

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

Вот почему они должны быть защищены парольной фразой.

Вы используете ssh-агент для хранения ключей в памяти, а для удобства можете хранить парольные фразы в связке ключей. В OpenSSH для macOS есть директива конфигурации UseKeychain для этого.

Я сам использую Yubikey/FIDO2, но не потому, что приватные ключи нельзя защитить в файловой системе.

Я довольный пользователь Secretive уже много лет, в том числе для подписи коммитов Git, для чего он использует отдельный ключ с взаимодействием, но не для pull / push. Я считаю этот компромисс идеальным для GitHub.com, и у меня есть другие ключи с другой настройкой для серверов.

SSH-ключи в открытом виде были одной из первых вещей, на которых сосредоточился наш bagel [0] для обнаружения секретов на конечных точках разработчика. Затем мы встроили bagel как библиотеку в нашу защиту конечных точек разработчика [1].

[0] https://boostsecurityio.github.io/bagel/

[1] https://boostsecurityio.github.io/dazio/docs/install/

Я использую `op` из 1Password для этого, но с оговоркой: ключи моей среды разработки.

Я обнаружил, что у меня началась усталость от отпечатков пальцев. Нужен ли запрос отпечатка каждый раз, когда мой сервер разработки хочет подключиться к dev Supabase? Нет. Это ожидаемо и не несёт никакого риска. Там нет данных.

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

Поэтому у меня есть отдельное хранилище 1Password, которое может читать сервисный аккаунт [0]. Этот токен находится в моей среде как OP_SERVICE_ACCOUNT_TOKEN, который понимает инструмент `op`.

У него также есть доступ к хранилищу с 'AI-безопасными' ключами, к которым я хочу, чтобы Claude имел доступ без запроса ко мне.

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

Я также держу элемент под названием '_One-day keys' в отдельном хранилище. (Подчёркивание просто перемещает его в начало списка для удобного доступа.)

В нём есть prod-ключи, в основном с ограниченным доступом только для чтения. При необходимости я перемещаю его в открытое хранилище. Claude знает об этом элементе и имеет инструкции напоминать мне переместить его обратно, когда он закончит то, что делал.

[0]: https://www.1password.dev/service-accounts/get-started

Вам стоит посмотреть на TKey (https://www.tillitis.se/products/tkey/)

Это, по сути, открытая версия YubiKey, само оборудование полностью открыто, и он отлично справляется с SSH-ключами ed25519.

inb4 они не одинаковые, я знаю, мне очень нравится то, что делает команда TKey.

Secure Enclave, TPM и другие подобные функции безопасности, к сожалению, так плохо документированы и требуют стольких прыжков через обручи, чтобы заставить их работать, причём любая ошибка либо полностью блокирует вас, либо не даёт желаемой защиты. Определённо должен быть лучший способ сделать эти технологии удобными...