Які обмеження щодо підписання спеціального коду?


14

Можна підписати код або програми "тимчасово" за допомогою codesign. Сторінка "man" повідомляє нам про підписання спеціального коду:

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

(Наголос додав я)

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

Що це за "значні обмеження" і де вони задокументовані?

Відповіді:


9

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

По суті, двійкові файли зазвичай підписуються додаванням так званої CMS (криптографічного повідомлення), де хеш CodeDirectory є повідомленням, яке підписується особою підпису. Це означає, що сторонній чоловік може перевірити, що код дійсно був підписаний тим, хто тримає приватний ключ для цієї особи.

Під час запуску програм система macOS може перевірити, чи є ці підписи дійсними, і що вона довіряє особі підпису - і, якщо це так, запустіть програму. Це основи функціональності GateKeeper.

Спеціальні підписані бінарні файли сильно відрізняються, оскільки вони не містять такої CMS. Натомість він просто містить хеш-значення SHA-1 CodeDirectory без будь-якого криптографічного підтвердження його дійсності та жодного шляху сертифікатів / ідентифікацій, які можна підтвердити.

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

Без криптографічного доказу цю "безшкодову" перевірку неможливо виконати у звичайному порядку.

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

По суті це означає, що "суттєві обмеження", застосовані до будь-якої програми, яку ви спеціально підписуєте, - це те, що вона нікуди не пройде ніякої перевірки. Це в основному те саме, що бінарне, яке не підписується.

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

На практиці створення розробників спеціальних бінарних файлів має лише практичне значення для розробників Apple.

Ви можете знайти незначну документацію про спеціальне підписання в розділі розробників Apple. Наприклад:

https://developer.apple.com/documentation/security/seccodesignatureflags/kseccodesignatureadhoc

Але ви також можете знайти фрагменти документів у вихідному коді самої утиліти кодування, а також у вихідному коді для забезпечення безпеки.


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

1
Значить лише для розробників, що працюють в Apple.
jksoegaard

Зауважте, що в тренажері iOS також використовується підписання adhoc. Підписання Adhoc може бути корисно для розробників за межами Apple, щоб програма могла вимагати права, що я не впевнений, що це можливо без підпису коду (усі документи, які я бачив, вказують на "ні"). На Mac це, як правило, не проблема, але в iOS багато функцій захищено за правами, тому для розробників iOS бажано перевірити правильність роботи.
дійне

@milch Ви змішуєте два непов'язані поняття - "підписання adhoc" (саме про це ішлося в цьому питанні) та "розповсюдження adhoc" (саме для цього розробник iOS часто використовує та стосується прав тощо)
jksoegaard

Я впевнений, що складання симуляторів підписані (не розповсюджуються). Ви можете перевірити, ознайомившись із додатком для iOS, створеним для тренажера codesign -dv --verbose=4 /path/to/the.app. Ви повернетеся до рядка Signature=adhoc, який говорить про те , що, схоже, вказує на підпис adhoc. В зокрема відсутня інші ключі , які зазвичай присутні в регулярно підписаному додатку IOS, такі як AuthorityіTeamIdentifier
Мільй
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.