Як захищений системний брелок в OS X?

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

Востаннє я перевіряв, що брелок для входу користувача в ОС X був настільки ж безпечним, як і пароль. Я пригадую певну проблему, яка зменшила фактичну секретність ключа на щось на зразок 111 біт (туманна пам'ять, будь ласка, не соромтеся виправити мене) через певну проблему з тим, як пароль перетворюється на ключ, але це було давно і сподіваємось, це було виправлено.

З іншого боку, мені сказали, що системний брелок за своєю суттю менш безпечний, тому що будь-який адміністратор може отримати доступ до нього, а зловмисник має багато варіантів стати адміністратором, окрім здогадуючись про пароль одного користувача.

Зокрема, я переживаю за збереження паролів, які використовуються в автоматизованих сценаріях, в системному брелоку, оскільки системні файли створюються резервними копіями та зберігаються за межами сайту без подальшого шифрування. Документи та інші дані користувачів шифруються перед тим, як виноситись із сайту, але у мене виникає підозра, що я проглядаю шлях, який відновлює ці ключі, коли системний брелок порушений (через наші процедури, не обов'язково криптографічні недоліки) . Тому я хочу глибоко зрозуміти, як системний брелок одночасно захищений, але доступний будь-якому адміністратору.

1. Яким чином архітектура ключів є такою, що будь-який адміністративний користувач може розблокувати системний брелок?

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

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

Мене цікавлять ОС X 10.5 Leopard та пізніші версії.

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

systemkeychain -vt

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

(Насправді я не відповідав на початкові запитання, тож давайте продовжимо це ще раз)

Яким чином архітектура ключів є такою, що будь-який адміністративний користувач може розблокувати системний брелок?

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

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

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

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

З огляду на незашифровану резервну копію системи без / Користувачі, як би ви отримали доступ до ключів у системній брелоці?

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

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

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

System Keychain,, /System/Library/Keychains/System.keychainє спеціальним брелоком для Apple і демонів, якими можна користуватися. Як правило, слід уникати використання його для сценаріїв користувачів.

Огляд коду: брелок

Apple опублікувала вихідний код для Keychain та системи безпеки для Mac OS X 10.5; ви можете переглянути цей код, щоб дізнатися, як він працює.

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

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

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

Я вдячний, що вилучення брелка з резервного копіювання не є ідеальним, але це вирішить ваші проблеми. Відновлюючи Mac, вам потрібно буде повернути брелок з іншого джерела; може бути більш надійним джерелом або бічним каналом.

Ви завжди можете зберігати пароль окремого брелка в системному брелоку. Потім ви могли розблокувати окремий брелок із сценарію. Якщо резервна копія атакується, ви виставите пароль лише окремому брелоку, а не самому брелоку, оскільки цей файл не має резервного копіювання за межами сайту.

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

У мене немає конкретних знань Keychain *, але це досить стандартизована практика.

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

Після цього ви можете змінити "пароль", ввівши поточну парольну фразу, розшифрувавши симетричний ключ, а потім зашифрувавши його новою парольною фразою. Це дозволяє уникнути тривалих процесів дешифрування / шифрування у випадку, якщо "foo" дуже великий.

То як це працює для декількох користувачів, яким потрібно отримати доступ до прямого тексту Foo? Насправді досить просто, ви просто створюєте зашифровану копію симетричного ключа один раз для кожного користувача. Іншими словами, зробіть крок третій для кожного користувача.

На практиці все це відсторонено від перегляду, і кінцевому користувачеві потрібно лише розбиратися зі своїм паролем.

Що стосується частини 3 ваших запитань, ключі користувачів не зберігаються у їхньому домі. Вони, швидше за все, будуть /private/varдесь зберігатися . Тож навіть без /Usersтого, хто раніше мав доступ, можна було б розблокувати систему.

* Можливо, що брелок працює по-іншому.