Как системная связка ключей защищена в OS X?


22

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

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

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

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

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

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

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

Я заинтересован в OS X 10.5 Leopard и более поздних версиях.


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

@ Алекс, сначала я попробовал Security.SE, но ответов там не получил.
Старый Pro

1
Почему бы не использовать отдельный брелок для всего, что вы делаете? Есть ли веская причина, по которой вашему скрипту нужен доступ к системной цепочке для ключей?
Джей Томпсон

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

Ответы:


11

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

systemkeychain -vt

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

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

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

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

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

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

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

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

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


1
Существует утилита dumpkeychain из GuidanceSoftware / EnCase, которая позволяет выполнять прямой дамп системной цепочки для ключей (с SystemKey) в Windows (может быть проще, чем установка новой установки OS X для ее дампирования).
drfrogsplat

1
@Анон, как я могу использовать вышеуказанную информацию для доступа / разблокировки / дампа System.keychain из резервной копии Time Machine другого компьютера? То есть у меня System.keychain и SystemKey хранятся на внешнем диске, поэтому я предполагаю, что должен указать пути к обоим файлам соответственно, чтобы избежать использования файлов в расположении по умолчанию.
дб

Этот пост имеет отношение (как использовать SystemKey для расшифровки System.keychain из старой системы). apple.stackexchange.com/questions/307189/… Мне любопытно, есть ли способ с помощью Keychain Access или systemkeychain cli разблокировать восстановленный System.keychain (то есть со старого разбитого жесткого диска) с соответствующим SystemKey из той же установки. Моя цель заключается в том, чтобы разблокировать и перенести имена входа в новую цепочку ключей системы при новой установке.
mattpr

5

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

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

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

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

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

Альтернативный подход: отдельный брелок

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

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

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

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


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

1
Я рекомендую спрашивать либо в списке рассылки Apple CDSA ( lists.apple.com/mailman/listinfo/apple-cdsa ), либо использовать инцидент технической поддержки Apple. Только с помощью этих средств вы сможете связаться с соответствующими инженерами Apple.
Грэм Милн

Запуск сценариев в фоновом режиме, поскольку root является задачей launchd. Что именно ты пытаешься сделать?
Джей Томпсон

1
Незначительная опечатка в "/System/Library/Keychains/System.keychain" (вы забыли "Библиотека"). На самом деле, вы можете получить список местоположений цепочки для ключей в Keychain Access, выбрав «Edit> Keychain List»
имя пользователя

1
@OldPro Учитывая ваши проблемы безопасности, почему бы не использовать полное шифрование диска?
Грэм Милн

2

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


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

Я рад принять вашу награду, если она направит вас в правильном направлении ;-)
demianturner

0

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

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

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

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

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

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


* Возможно, что брелок работает по-другому.


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

Опять же , я могу только догадка, но ИМО это на самом деле не что разные. Сама система, очевидно, может получить ключ, который предоставлен. Я бы предположил, что есть системный ключ, обработанный аналогично пользовательским ключам. Но теперь мы в центре вашего вопроса ... что обеспечивает первый доступ?
Багамат
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.