Jakie są ograniczenia podpisywania kodu ad-hoc?


14

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?

Odpowiedzi:


9

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.


Czy „tylko praktyczna wartość dla programistów Apple” oznacza tutaj „tylko dla programistów pracujących w Apple”, czy „tylko dla programistów pracujących na platformach Apple”? Naprawdę ciekawy, ponieważ zaczęliśmy otrzymywać nowy problem, w którym pęku kluczy nie można znaleźć klucza, nawet jeśli nazwa jest poprawna, i rozważamy przejście na łącznik w wersjach nie wydanych.
Trejkaz,

1
Oznacza tylko dla programistów pracujących w Apple.
jksoegaard

Pamiętaj, że symulator iOS również używa podpisywania adhoc. Podpisywanie ad hoc może być przydatne dla programistów spoza Apple, aby umożliwić aplikacji żądanie uprawnień, co nie jestem pewien, czy jest możliwe bez podpisu kodu (wszystkie dokumenty, które widziałem, wskazują na brak). Na Macu zwykle nie stanowi to problemu, ale na iOS wiele funkcji nie ma uprawnień, więc testowanie, czy działa poprawnie, jest pożądane dla programistów iOS.
mlecz

@milch Mieszasz dwie niepowiązane koncepcje - „podpisywanie ad hoc” (o to chodziło w tym pytaniu) i „dystrybucja adhoc” (to jest to, czego deweloper iOS często używa i dotyczy uprawnień itp.)
jksoegaard

Jestem pewien, że kompilacje symulatorów są podpisane ad hoc (nie dystrybuowane). Możesz to sprawdzić, sprawdzając aplikację iOS zbudowaną dla symulatora za pomocą codesign -dv --verbose=4 /path/to/the.app. Otrzymasz wiersz z napisem Signature=adhoc, który wydaje się wskazywać na podpis ad-hoc. Szczególnie nieobecne są inne klucze, które są zwykle obecne w regularnie podpisywanej aplikacji na system iOS, takie jak AuthorityiTeamIdentifier
milch
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.