Jakie są ograniczenia podpisywania kodu ad-hoc?

Możliwe jest podpisanie kodu lub aplikacji „ad-hoc” za pomocą codesign. Strona podręcznika informuje nas o podpisywaniu kodu ad-hoc:

Jeśli tożsamość jest pojedynczą literą „-” (myślnik), wykonywane jest podpisywanie ad-hoc. Podpisywanie ad-hoc w ogóle nie używa tożsamości i dokładnie identyfikuje jedno wystąpienie kodu. Znaczące ograniczenia dotyczą stosowania podpisanego kodu ad-hoc; przed użyciem zapoznaj się z dokumentacją.

(Podkreślenie dodane przeze mnie)

Chciałem dowiedzieć się więcej i próbowałem znaleźć wspomnianą dokumentację, ale nie mogłem znaleźć żadnych szczegółów. Znalazłem notatkę techniczną o nazwie „Głębokość podpisywania kodu macOS” , ale w ogóle nie wspomina o podpisywaniu ad-hoc.

Jakie są te „znaczące ograniczenia” i gdzie są udokumentowane?

Zasadniczo podpisywanie ad-hoc w tym kontekście oznacza, że ​​plik binarny jest podpisany bez żadnego dowodu kryptograficznego.

Zasadniczo pliki binarne są zwykle podpisywane przez dodanie tak zwanego CMS (wiadomości kryptograficznej), w której skrótem CodeDirectory jest wiadomość podpisana przez tożsamość podpisującego. Oznacza to, że osoba z zewnątrz może sprawdzić, czy kod rzeczywiście został podpisany przez osobę posiadającą klucz prywatny dla tej tożsamości.

Podczas uruchamiania programów system macOS może sprawdzić, czy te podpisy są prawidłowe i czy ufa tożsamości podpisującego - a jeśli tak, uruchom program. To są podstawy funkcjonalności GateKeeper.

Pliki binarne ze znakiem ad hoc różnią się znacznie, ponieważ nie zawierają takiego CMS. Zamiast tego po prostu przechowuje wartość skrótu SHA-1 w CodeDirectory bez żadnego kryptograficznego dowodu jego ważności i bez ścieżki certyfikatów / tożsamości do weryfikacji.

CodeDirectory to obiekt, który opisuje określone wystąpienie kodu statycznego poprzez posiadanie wartości skrótu dla różnych fragmentów kodu, z których wykonana jest aplikacja. Zapewniając, że CodeDirectory nie zostanie naruszony, weryfikując podpis kryptograficzny oraz że różne bity kodu aplikacji są zgodne z wartościami skrótu przechowywanymi w katalogu, możesz upewnić się, że kod nie został zmieniony.

Bez dowodu kryptograficznego tej „niezakłóconej” kontroli nie można wykonać w normalny sposób.

Zamiast tego sprawdzane są pliki binarne ze znakiem ad-hoc poprzez porównanie wartości skrótu SHA-1 z listą „znanych dobrych” wartości skrótu przechowywanych w statycznej pamięci podręcznej zaufania w jądrze.

Zasadniczo oznacza to, że „znaczące ograniczenia” nakładane na dowolną aplikację, którą sam podpisujesz ad hoc, to że nie przejdzie ona żadnej weryfikacji. Zasadniczo jest taki sam, jak nie podpisany plik binarny.

Jednak jeśli jesteś Apple, możesz tworzyć aplikacje, które nie są kodowane w zwykły sposób, a zamiast tego są jawnie zaufane przez jądro. Tzn. Jeśli na przykład Apple chce upewnić się, że aplikacja nie jest zakłócana podczas uruchamiania na wczesnym etapie uruchamiania systemu, gdy pełna weryfikacja tożsamości podpisywania nie jest uruchomiona (lub jest niedostępna), może użyć podpisywania ad-hoc. Aplikacje te zawsze można zweryfikować za pomocą statycznej pamięci podręcznej zaufania, bez względu na to, czy repozytorium certyfikatów jest ukryte, czy coś podobnego.

W praktyce tworzenie podpisanych plików binarnych ad hoc ma praktyczną wartość tylko dla programistów Apple.

Drobną dokumentację dotyczącą podpisywania ad hoc można znaleźć w sekcji dla programistów Apple. Na przykład:

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

Ale fragmenty dokumentów można także znaleźć w kodzie źródłowym samego narzędzia codeign oraz w kodzie źródłowym libsecurity.