Как цепочка ключей системы защищена в OS X?

Я ищу что-то вроде этого документа по безопасности для iOS , кроме OS X, или, что еще лучше, какой-то отчет об аудите безопасности от независимого эксперта. После прочтения документации, такой как « Руководство по программированию служб цепочки ключей» , я еще больше запутался в том, что уязвимо для состязательной атаки на незашифрованную резервную копию системы OS X.

В прошлый раз, когда я проверял, цепочка ключей входа пользователя в OS X была примерно такой же безопасной, как и пароль. Я припоминаю некоторую проблему, из-за которой фактическая секретность ключа сократилась примерно до 111 бит (туманная память, пожалуйста, не стесняйтесь меня поправлять) из-за какой-то проблемы с преобразованием пароля в ключ, но это было давным-давно и надеюсь, это было исправлено.

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

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

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

  2. Существуют ли криптографические ограничения, которые каким-либо образом ограничивают действия администратора с информацией в системной цепочке ключей?

  3. Учитывая незашифрованную резервную копию системы без /Users , как бы вы получили доступ к ключам в системной цепочке ключей?

Я заинтересован в OS X 10.5 Leopard и более поздних версиях, но конкретно ограничен настольными компьютерами или ноутбуками Mac без чипа T2 или защищенного анклава. В официальном документе Apple по безопасности платформы весной 2020 года довольно хорошо объясняется, что критические ключи, шифрующие данные связки ключей, хранятся на чипе T2, а сам чип T2 управляет и применяет ACL, которые ограничивают доступ к функциям дешифрования. Таким образом, на этих компьютерах, как и на всех устройствах iOS, база данных связки ключей привязана к оборудованию и не может использоваться на другом устройстве.

У меня нет ответа, но есть анекдот: как обычный пользователь без прав администратора я когда-то смог относительно легко извлечь пароли из цепочки ключей System. Я не помню точных шагов, но это, безусловно, было возможно. Кстати, может быть, это лучше на security.stackexchange.com ?
@ Алекс, сначала я попробовал Security.SE, но не получил там ответов.
Почему бы не использовать отдельную связку ключей для того, что вы делаете? Есть ли веская причина, по которой вашему сценарию нужен доступ к системной связке ключей?
@eyemyth, да, сценарии должны запускаться системой, чтобы они могли получить доступ ко всем файлам на диске независимо от разрешений пользователя.

Ответы (4)

Системная цепочка ключей хранится в /Library/Keychains/System.keychainнем, а ключ для ее разблокировки хранится в нем /var/db/SystemKey(его права доступа к файлам по умолчанию доступны для чтения только пользователю root). Расположение этих файлов указано в скрипте security-checksystem (из источника security_systemkeychain ). Можно даже протестировать автоматическую блокировку/разблокировку системного брелка с помощью

systemkeychain -vt

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

(На самом деле я не ответил на первоначальные вопросы, так что давайте попробуем еще раз)

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

Платформа цепочки для ключей libsecurity позволяет обычным процессам взаимодействовать с системной цепочкой для ключей с проверкой подлинности, используя структуру межпроцессного взаимодействия Apple XPC (IPC).

Программа А отправляет запрос на доступ к системной информации о связке ключей с помощью IPC. Выполняется проверка того, что запрашивающий пользователь уже находится в группе wheel, а также знает пароль пользователя в группе wheel. После подтверждения авторизации привилегированный kcproxyдемон можно использовать для доступа к материалам в /var/db/SystemKey, разблокировать системную связку ключей и вернуть запрошенную информацию.

Существуют ли криптографические ограничения, которые каким-либо образом ограничивают действия администратора с информацией в системной цепочке ключей?

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

Учитывая незашифрованную резервную копию системы без /Users, как вы получите доступ к ключам в системной связке ключей?

Если бы резервная копия содержала копии, /Library/Keychains/System.keychainа /var/db/SystemKeyзатем я бы скопировал их в соответствующие места в новой системе OS X и использовал systemkeychain, чтобы сделать более позднюю разблокировку первой и создать дамп базы данных цепочки для ключей, используя файлы security dump-keychain.

Существует утилита dumpkeychain от GuidanceSoftware/EnCase, которая позволяет напрямую создавать дамп системной цепочки ключей (с SystemKey) в Windows (может быть проще, чем настраивать новую установку OS X для ее дампа).
@ Анон, как я могу использовать приведенную выше информацию для доступа / разблокировки / дампа System.keychain из резервной копии Time Machine другого компьютера? То есть у меня есть System.keychain и SystemKey, хранящиеся на внешнем диске, поэтому я думаю, что должен указать пути к обоим файлам соответственно, чтобы избежать использования файлов в расположении по умолчанию.
Этот пост связан (как использовать SystemKey для расшифровки System.keychain из старой системы). apple.stackexchange.com/questions/307189/… Мне любопытно, есть ли способ с помощью Keychain Access или systemkeychain cli разблокировать восстановленную System.keychain (т.е. со старого разбитого жесткого диска) с помощью соответствующего SystemKey из той же установки. Моя цель - разблокировать и перенести логины в новую системную цепочку ключей при новой установке.

Системный брелок

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

Системная цепочка для ключей /System/Library/Keychains/System.keychain— это специальная цепочка для ключей, которую могут использовать Apple и демоны. Как правило, вам следует избегать его использования для сценариев пользовательского уровня.

Обзор кода: брелок

Apple опубликовала исходный код цепочки для ключей и системы безопасности для Mac OS X 10.5; вы можете просмотреть этот код, чтобы узнать, как он работает.

Альтернативный подход: отдельная цепочка для ключей

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

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

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

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

Спасибо, но мне слишком сложно понять из всего этого кода, как защищена системная цепочка ключей и что обеспечивает ее безопасность. Нам нужно использовать системную связку ключей, потому что нам нужно, чтобы сценарии запускались автоматически в фоновом режиме с привилегиями root независимо от того, кто вошел в систему.
Я рекомендую задать вопрос либо в списке рассылки Apple CDSA ( lists.apple.com/mailman/listinfo/apple-cdsa ), либо с помощью обращения в службу технической поддержки Apple. Только с помощью этих средств вы сможете связаться с соответствующими инженерами Apple.
Запуск скриптов в фоновом режиме от root — это работа launchd. Что именно ты пытаешься сделать?
Незначительная опечатка в "/System/Library/Keychains/System.keychain" (Вы забыли "Библиотека"). На самом деле, вы можете получить список местоположений связки ключей в Keychain Access, выбрав «Edit > Keychain List».
@username Спасибо. Я исправил путь к системной связке ключей по умолчанию.
Наличие отдельного брелка не помогает, потому что мне все еще нужна система, чтобы разблокировать его, и я не знаю, как сделать это безопасно. Кроме того, исключение чего-либо из резервного копирования чрезвычайно подвержено ошибкам, поскольку резервное копирование происходит на нескольких уровнях, включая клонирование всего диска на уровне блоков.
@OldPro Учитывая ваши проблемы с безопасностью, почему бы не использовать полное шифрование диска?

Apple недавно опубликовала документ с изложением своих методов обеспечения безопасности , вы можете найти там некоторые ответы. Документ специфичен для iOS, но многие функции безопасности имеют много общего с OS X.

Это на правильном пути, и это хороший пример документации, которую я бы нашел полезной, но в iOS нет концепции System Keychain, поэтому она не отвечает на мой вопрос.
Я рад принять вашу награду, если это приведет вас в правильном направлении ;-)

У меня нет особых знаний о связке ключей*, но это довольно стандартизированная практика.

  1. Вы хотите защитить обычный текстовый файл "foo". Foo может быть произвольного размера.
  2. Создайте симметричный ключ для шифрования foo.
  3. Зашифруйте симметричный ключ с помощью ключа, полученного из парольной фразы.

После этого вы можете изменить «пароль», введя текущую фразу-пароль, расшифровав симметричный ключ, а затем зашифровав его новой фразой-паролем. Это позволяет избежать длительных процессов расшифровки/шифрования в случае, если "foo" очень большой.

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

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

Что касается части 3 вашего вопроса, ключи пользователей не хранятся у них дома. Скорее всего, они где- /private/varто хранятся. Так что даже без /Usersтого, кто ранее имел доступ, сможет разблокировать систему.

*Возможно, Брелок работает иначе.

Отличие системной цепочки для ключей заключается в том, что система может получить доступ к цепочке для ключей независимо от того, кто вошел в систему. Например, Time Machine может получить доступ к системной цепочке для ключей для подключения удаленного общего файлового ресурса, даже если единственный зарегистрированный пользователь не является пользователь с правами администратора и, следовательно, не может получить доступ к системной связке ключей. Значит, происходит что-то еще, и я хотел бы точно знать, что именно.
Опять же, я могу только предполагать, но IMO на самом деле не так уж и отличается. Очевидно, что сама система может получить ключ, это само собой разумеющееся. Я бы предположил, что системный ключ обрабатывается аналогично пользовательским ключам. Но теперь мы подошли к сути вашего вопроса… что обеспечивает первый доступ?
Как цепочка ключей системы защищена в OS X?
СпросиСетьПолитика конфиденциальности1y, 0v