—+ КРАТКО

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

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

Я задаю этот вопрос, стремясь получить доступ к Gmail с помощью gmi/lieer и notmuch – которые, насколько я могу судить, используют незашифрованный файл учетных данных на диске. Но существует множество других программ, которые требуют аналогичных файлов учетных данных.

Уверен, должна существовать универсальная решение этой проблемы? Что-то вроде ssh-agent, который спрашивает у пользователя пароль и затем расшифровывает секреты в память на некоторое время. Но не обязательно так же сложно, как ssh-agent… агенту не нужно выполнять все криптографические операции, которые могут различаться в зависимости от приложения или API или протокола. На мой взгляд, просто расшифровка файла учетных данных в память была бы полезной.

—+ Краткое содержание – Здесь можно остановиться, не читая дальше

Некоторые люди поймут, что я запрашиваю, исходя из вышеуказанного КРАТКОГО раздела.

Другие, вероятно, нет.

—+ Должно быть, существует универсальное решение этой проблемы?

Наверняка есть что-то вроде ssh-agent, который читает такие секреты из зашифрованного файла, спрашивает у пользователя пароль (или лучше), расшифровывает секреты и хранит их только в памяти на некоторое время, чтобы не приходилось постоянно вводить пароль и т. д.?

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

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

Но я, безусловно, не знаю ни о чем подобном.

—+ Google или ChatGPT тоже не знают

Тем более, ни один из AI-помощников, которые я пробовал, – хотя это может быть вопрос в том, что я неправильно сформулировал запрос к LLM или поиск в Google.

ChatGPT предложил мне сделать следующее:

• зашифровать файл учетных данных на диске
• когда я хочу его использовать
  • временно создать незашифрованный файл учетных данных – на диске
  • позволить клиентской программе, такой как gmi/lieer, получить доступ к незашифрованному файлу учетных данных, пока она работает
  • и когда я больше не запущу клиента, удалить незашифрованный временный файл учетных данных

Надеюсь, мне не нужно объяснять, насколько это неудовлетворительно.

—+ Может ли это быть сделано с использованием UNIX доменных сокетов или FUSE? Это уже было сделано?

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

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

• Используя UNIX доменные сокеты
• или FUSE
• или что-то другое

Еще лучше, если такое изменение пространства имен было бы ограничено родительским процессом и его потомками, как можно было бы сделать в операционных системах, таких как Plan9 или Brazil, хотя, насколько я знаю, существующие UNIX-системы, такие как Linux, не облегчают это.

—+ ДЕТАЛЬ

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

Поэтому я предоставляю все эти дополнительные детали, надеясь восполнить недопонимания.

Если вы действительно знаете ответ на мой вопрос, вы можете, вероятно, остановиться, не читая всего остального.

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

—+ Мотивирующий пример: доступ gmi/lieer к gmail использует незашифрованный файл учетных данных

Например, lieer, программа для синхронизации gmail с локальным хранилищем, хранит незашифрованный файл учетных данных для Gmail в файловой системе. Этот файл, .credentials.gmailieer.json, полностью незашифрованный обыкновенный открытый текст.

Извлечение: https://github.com/gauteh/lieer?tab=readme-ov-file#usage

gmi init теперь откроет ваш браузер и запросит ограниченный доступ к вашей электронной почте.
…
Токен доступа хранится в .credentials.gmailieer.json в локальном почтовом репозитории. Если хотите, вы можете указать свой собственный api ключ, который будет использоваться.

Конечно, права доступа к файлам должны сделать его доступным только для моего идентификатора UNIX. Он используется программой gmi/lieer для доступа к моему аккаунту Gmail. Но если я полностью не упускаю что-то, любая программа, работающая от моего имени, может получить доступ к этому файлу. Например, один из множества побегов из песочницы в веб-браузерах может позволить получить доступ к этому файлу. Или я мог неправильно настроить права на файловую систему. Или я мог неправильно настроить шифрование файловой системы/диска, и другие идентификаторы пользователей на моей машине могут получить доступ к нему. И так далее.

Я думал, что это стандартная/лучшая практика в области безопасности, что открытые секреты никогда не должны храниться на диске. Я давно удивлялся, сколько программных систем требуют хранения учетных данных, таких как ключи API, на диске. Обычно я избегал использования таких систем, хотя это мешает таким вещам, как разработка API Google, которые требуют таких ключей API. Или я мог бы использовать такие системы или работать, но сопротивляться их использованию для личных вещей. Тем не менее, мне действительно хотелось бы использовать такие системы для личных нужд. Не только для личной разработки программного обеспечения, но и для доступа gmi/lieer к моему аккаунту Gmail, что является самым личным, что я могу себе представить, гораздо более чувствительным для меня, чем проект на GitHub.

Это не просто проблема с gmi/lieer. Многие программы, многие программные системы требуют от вас хранить учетные данные, такие как ключи API, на диске. Я не думаю, что я встречал хоть одну из них, которая хранит их зашифрованными на диске.

Кроме, конечно, ssh/ssh-agent и gpg/gpg-agent, где файлы учетных данных защищены не только правами доступа к файловой системе, но и паролем и расшифровываются только в памяти процесса ssh-agent.

—+ ssh-agent => никаких открытых учетных данных на диске

Кроме, конечно, ssh/ssh-agent и gpg/gpg-agent.

• Где файлы ключей защищены
  • не только защищены правами доступа к файловой системе,
    но также зашифрованы паролем.
    • Когда вы загружаете ID в ssh-agent
      • он запрашивает у вас пароль,
      • читает зашифрованные файлы ключей,
      • и расшифровывает их в память своего процесса.
      • ssh-agent является постоянным, так что вам нужно делать это только время от времени
    • ssh, если он правильно настроен,
      • не сможет работать, не попросив ssh-agent “сделать что-то”.
      • общается с ssh-agent через UNIX доменной сокет
      • ssh-agent фактически выполняет все или большинство вычислений с открытым ключом
      • => сам ssh не имеет закрытых ключей

Я думал, что это стандартная/лучшая практика в области безопасности, что

1. Открытые секреты никогда не должны храниться на диске

   • с возможным исключением файлов подкачки,
     • но это должно быть решенной проблемой
   • так что даже если кто-то может получить доступ к сырым данным на диске, вы должны быть в безопасности
     • например, если у вас нет полного шифрования диска или файловой системы
     • и дисковый привод доступен вне его “родной” ОС

2. Открытые личные ключи могут храниться в памяти процесса ssh-agent

   • не в программе ssh-клиента
   • и не должны быть доступны никаким другим программам,
     • даже работающим от того же пользователя на одной машине
     • возможно, также не более привилегированным пользователям, таким как root или администратор
       • с возможным исключением отладчиков
       • но это также должно быть решенной проблемой (хотя у меня такого опыта не было)

—+ Идти дальше, чем ssh-agent…

Пропустите этот раздел, он не так уж важен для моего вопроса, кроме того, что помогает мне организовать вопросы в моей голове. Кроме того, если кто-то может сказать мне, что эти пункты (3) и (4) ниже используются в гораздо более широком масштабе, чем я сейчас знаю, мне было бы интересно это услышать.

Пункты (1) и (2) являются, насколько мне известно, современным состоянием дел или, по крайней мере, практикой. Но они оставляют некоторые уязвимости в оборудовании/логическом анализаторе, которые были решены определенными академическими и отраслевыми проектами, но которые, насколько мне известно, гораздо менее распространены:

3. В большинстве современных систем открытые секреты могут храниться в DRAM

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

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

• 2.5: меня на самом деле немного беспокоит, что связь клиента/агента ssh выполняется через UNIX доменный сокет
  • насколько мне известно, любой процесс, работающий с соответствующим идентификатором пользователя, может получить доступ к этому сокету и заставить ssh-agent делать что-то
  • насколько мне известно, UNIX доменный сокет защищен только правами доступа к файловой системе
    • насколько мне известно, ssh-agent и программа ssh не общаются через зашифрованный канал
  • Хотя тот факт, что UNIX доменный сокет может быть несколько случайным, уменьшает подверженность.
    И я знаю, что некоторые операционные системы – не стандартный LINUX, насколько мне известно – позволяют ограничивать права доступа не только по идентификатору пользователя, но и по идентификатору исполняемого файла или позиции в дереве процессов.
  • Вы, конечно, можете использовать JNIX идентификаторы пользователей для достижения этого, но, насколько я знаю, это не часто делается.

—++ Пример: файл открытого текста, содержащий учетные данные gmail для gmi/lieer

gmi/lieer, программа для синхронизации gmail с локальным хранилищем, хранит незашифрованный файл учетных данных для Gmail в файловой системе

Извлечение: https://github.com/gauteh/lieer?tab=readme-ov-file#usage

gmi init теперь откроет ваш браузер и запросит ограниченный доступ к вашей электронной почте.
…
Токен доступа хранится в .credentials.gmailieer.json в локальном почтовом репозитории. Если хотите, вы можете указать свой собственный api ключ, который будет использоваться.

Учетная запись lieer выглядит следующим образом. Я надеюсь, что я удалил все, что может быть чувствительным. “Бессмыслица” – это, конечно, то, что похоже на случайные буквы и цифры с редкими знаками препинания, то, что обычно ассоциируют с учетными данными.

{"access_token": "xyzzy ~200 байтов бессмыслицы",
 "client_id": "~40 байтов бессмыслицы.apps.googleusercontent.com",
 "client_secret": "~20 байтов бессмыслицы",
 "refresh_token": "~100 байтов бессмыслицы",
 "token_expiry": "2024-09-15T07:16:24Z",
 "token_uri": "https://accounts.google.com/o/oauth2/token",
 "user_agent": "Lieer",
 "revoke_uri": "https://oauth2.googleapis.com/revoke",
 "id_token": null,
 "id_token_jwt": null,
 "token_response": {"access_token": "~200 байтов бессмыслицы",
 "expires_in": 3599,
 "scope": "https://www.googleapis.com/auth/gmail.readonly https://www.googleapis.com/auth/gmail.modify https://www.googleapis.com/auth/gmail.labels",
 "token_type": "Bearer"},
 "scopes": ["https://www.googleapis.com/auth/gmail.labels",
 "https://www.googleapis.com/auth/gmail.readonly",
 "https://www.googleapis.com/auth/gmail.modify"],
 "token_info_uri": "https://oauth2.googleapis.com/tokeninfo",
 "invalid": false,
 "_class": "OAuth2Credentials",
 "_module": "oauth2client.client"
}

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

Он используется программой gmi для аутентификации в Gmail. Если он отсутствует, я не могу получить доступ к своему Gmail. Меня не просят ввести пароль и т. д.

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

—++ Это не только gmi/lieer — много программ

Я не собираюсь утомлять себя перечислением дополнительных примеров. Но просто поисковый запрос API KEY должен дать множество таких примеров.

—++ Это просто устаревшее программное обеспечение?

Возможно, но на мой взгляд, не совсем.

Например, исходный код gmi/lieer и/или документация указывает на то, что он использует старый API Gmail и должен быть обновлен. Возможно, более современные API решают эту проблему, – но, насколько я могу судить, нет. Возможно, уже существует универсальный OpenAuth-агент – но я не могу его найти. Насколько я понял, Google действительно предпочитает держать OpenAuth в своих собственных библиотеках, используемых Google Chrome и другими веб-браузерами, и не слишком много сделал для поддержки командной строки или других неклассных утилит. Им действительно бы хотелось, чтобы вы не использовали такие утилиты, если их не написала Google. Они лишь с неохотой поддерживают такие утилиты, позволяя вам получать API KEY и т. д. Если есть уязвимости безопасности, вызванные хранением таких учетных данных незашифрованными на диске, они просто используют это как еще одно доказательство, чтобы оправдать закрытие и блокировку другого программного обеспечения.

В любом случае: если существует универсальный OpenAuth-агент (вероятно, не так названный) – я был бы рад об этом услышать.

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

Вы изучили множество возможных путей и провели много исследований в этой проблемной области; отлично (включите голосование за вопрос).

Но я думаю, что у вас есть ответ; универсального решения нет. Инструменты, такие как ssh-agent (или gpg-agent), требуют, чтобы программное обеспечение было написано таким образом, чтобы работать с ними. Если программа написана просто для чтения файла с диска, тогда она никогда не сможет взаимодействовать с этими агентами.

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

Другие инструменты (например, rclone) могут зашифровать свои конфигурационные файлы и требуют от вас ввода пароля для их использования.

Даже на устройствах Apple приложения должны быть написаны для общения с хранилищем ключей (keychain), чтобы безопасно сохранять учетные данные.

Так можем ли мы это замять? Это зависит от уровня вашего параноидального настроя (и программного обеспечения).

Например, вы можете создать зашифрованную файловую систему. Это не обязательно должна быть раздел; это может быть файл, который вы создаете в существующей файловой системе и монтируете. Смотрите luks и сопутствующие инструменты. Это защитит ваши данные от похищения диска, так как требует от вас ввода пароля для расшифровки диска. Тогда вы можете потенциально создать символьные ссылки или связываемые точки монтирования для конфигурационных файлов в эту файловую систему.

Как и прежде, это не защитит вас от пользователей root или вредоносных программ, которые могут читать ваши файлы, так как файл доступен для чтения после монтирования. Но это защищает от кражи (например, потерянный ноутбук). Хотя вам, возможно, стоит рассмотреть возможность шифрования всей файловой системы, если это ваша проблема. Если все зашифровано, то ваши конфигурационные файлы тоже находятся под защитой!

Если вы хотите требовать события повторной аутентификации время от времени (“о, прошло час с тех пор, как я в последний раз вводил пароль”), то все усложняется. Я не знаю ни о каком “из коробки” решении. Я бы рассмотрел возможность написания файловой системы FUSE, которая могла бы монтироваться и требовать ввода пароля раз в час для продолжения расшифровки.