W jaki sposób podpisywanie pod silną nazwą chroni przed tworzeniem zestawu złożeń?

Question

Podpisanie z silną nazwą (keypair przechowywane w pliku .snk) jest (między innymi) przeznaczone na protect against forging assemblies.

Na przykład: Wysyłam moje zgłoszenie podpisane silną nazwą, następnie jakiś inny programista używa mojego zestawu, więc jego zestaw zawiera teraz odniesienie do mojego, wspominając o kluczu publicznym mojego klucza. Niektórzy użytkownicy instalują ten zestaw deweloperski i mój zespół iz przyjemnością używają kodu tego dewelopera. Jeśli ktokolwiek spróbuje wyprodukować zestaw wyglądający jak moja wersja i przekonać użytkownika, że ​​jest to "aktualizacja warta instalacji", to podrobiony montaż nie zostanie załadowany, ponieważ kontroluję mój klucz i ten sfałszowany montaż nie jest podpisany za pomocą tego samego klucza. . Ok spoko.

Co jednak powstrzymuje złośliwą stronę przed wykuwaniem zarówno mojego zespołu, jak i tego zależnego zespołu innego programisty i "wysyłania" ich obu? Chwytają mój zespół i ten zespół dewelopera, manipulują obydwoma, podpisują fałszywą wersję mojego zespołu za pomocą dowolnego klucza, a następnie dodają do niego odwołanie do sfałszowanej wersji zespołu zależnego, podpisują go również, a następnie wysyłają oba. Mam na myśli złośliwie "wysyłanie" dwóch zestawów nie powinno być dużo trudniejsze niż "wysyłka" jednego zestawu.

W jaki sposób podpisywanie z silnymi nazwami chroni przed fałszowaniem wielu zespołów?

Answer 1

Mocne nazewnictwo zespołu nie ma na celu ochrony podpisanego zespołu. Ma on chronić drugi zespół, który ładuje podpisany zespół.

Na przykład, jeśli plik EXE jest zaufany i chce załadować znaną bibliotekę DLL ze znanej lokalizacji (takiej jak GAC, udział sieciowy, internet itd.), Może to zrobić, używając silnej nazwy z pewnym poziomem pewność, że montaż nie został naruszony.

Ale jeśli cały zestaw złożeń zostanie zdemontowany, a następnie ponownie złożony i ponownie podpisany, to tak, masz rację, że można po prostu ponownie napisać linie kodu, które ładują pozostałe zespoły, tak aby ładuje je nowym (fałszywym) kluczem.

Ale ten rodzaj ingerencji byłby oczywisty. Innymi słowy, silne podpisywanie nazw zapewnia wyraźne dowody manipulacji, ale nie zapobiega mu we wszystkich przypadkach. Dodajmy do tego fakt, że administrator lokalny może całkowicie wyłączyć silną weryfikację nazwy (w celu "rozwoju") i oczywiste jest, że silne podpisywanie nazw nie jest kuloodpornym mechanizmem bezpieczeństwa.

To samo dotyczy podpisu Authenticode i kierowcy. Wszyscy widzieliśmy produkt, który poleca użytkownikom "zignorować ostrzeżenie o zabezpieczeniach". Zasadniczo to, co zrobiłby EXE, gdyby silna weryfikacja nazwy była wyłączona lub cały zestaw złożeń był pozbawiony sygnatur - byłoby ignorowanie ostrzeżenia.

Answer 2

Silne Nazewnictwo to wszystko, cóż ... "Nazywanie". Cytuję stąd: Using Strong Name Signatures

"Silne nazwy oferują potężny mechanizm zapewniający niepowtarzalne tożsamości zestawów .NET Framework."

To wszystko, co dostaniesz z tego mechanizmu. Oznacza to, że mogę wykuć twoje zgromadzenie i wszystkie zgromadzenia, do których się odwołuje, ale nie będę w stanie udawać, że "to zrobiłeś". Nie będę mógł udawać, że jesteś jednym z wydawców tych zespołów.