Jaka jest rola tokena klucza publicznego?

Jaka jest rola tokena klucza publicznego? Czy ma jakikolwiek udział w odszyfrowaniu podpisanego skrótu? Dlaczego w GAC jest tak wiele zestawów firmy Microsoft z tym samym tokenem klucza publicznego?

Jaka jest rola tokena klucza publicznego?

Token klucza publicznego to mała liczba, która jest wygodnym „tokenem” reprezentującym klucz publiczny. Klucze publiczne są dość długie; celem tokena klucza publicznego jest umożliwienie odwoływania się do kluczy bez wypowiadania całego klucza. W ten sam sposób powiedzenie „Władca Pierścieni” to pięć słów, które reprezentują powieść zawierającą pół miliona słów. Byłoby raczej niewygodne, gdybyś za każdym razem, gdy chciał o tym porozmawiać, musiał wypowiedzieć te pół miliona słów.

Czy ma jakikolwiek udział w odszyfrowaniu podpisanego skrótu?

Nie. Token klucza publicznego nie zawiera żadnych „informacji”. To tylko liczba reprezentująca klucz publiczny. Sam w sobie nie jest kluczem publicznym.

dlaczego jest tak wiele zestawów firmy Microsoft z tym samym tokenem klucza publicznego?

Ponieważ wszystkie zostały podpisane tym samym kluczem prywatnym - kluczem prywatnym firmy Microsoft - i dlatego wszystkie są weryfikowane tym samym kluczem publicznym, a zatem wszystkie mają ten sam token klucza publicznego.

Z Wikipedii

„Token klucza publicznego jest używany do uczynienia nazwy zestawu unikatową. Dlatego dwa silnie nazwane zestawy mogą mieć tę samą nazwę pliku PE, a mimo to .NET rozpozna je jako różne zestawy. System plików Windows (FAT32 i NTFS) rozpoznaje tylko Nazwa pliku PE, więc dwa zestawy z tą samą nazwą pliku PE (ale inną kulturą, wersją lub tokenem klucza publicznego) nie mogą istnieć w tym samym folderze Windows. Aby rozwiązać ten problem .NET wprowadza coś, co nazywa się GAC (Global Assembly Cache), traktowany jako pojedynczy folder przez środowisko .NET CLR, ale w rzeczywistości jest zaimplementowany przy użyciu zagnieżdżonych folderów NTFS (lub FAT32).

Aby zapobiec atakom podszywającym się, w których cracker próbowałby udawać, że zestaw wygląda jak coś innego, zestaw jest podpisywany kluczem prywatnym. Twórca zamierzonego zestawu utrzymuje klucz prywatny w tajemnicy, więc cracker nie może mieć do niego dostępu ani po prostu go odgadnąć. W ten sposób cracker nie może zmusić swojego zespołu do podszywania się pod coś innego, bez możliwości poprawnego podpisania go po zmianie. Podpisanie zestawu obejmuje pobranie skrótu ważnych części zestawu, a następnie zaszyfrowanie skrótu za pomocą klucza prywatnego. Podpisany skrót jest przechowywany w zestawie wraz z kluczem publicznym.Klucz publiczny odszyfruje podpisany skrót.Gdy środowisko CLR ładuje zestaw o silnej nazwie, wygeneruje skrót z zestawu, a następnie porówna go z odszyfrowanym skrótem. Jeśli porównanie powiedzie się, oznacza to, że klucz publiczny w pliku (a tym samym token klucza publicznego) jest skojarzony z kluczem prywatnym używanym do podpisywania zestawu. Oznacza to, że klucz publiczny w zestawie jest kluczem publicznym wydawcy zestawu, a tym samym udaremniony jest fałszywy atak. "

Hash to rodzaj „odcisku palca”. Jest podpisany przy użyciu klucza prywatnego, którego właścicielem (i tylko znany) jest osoba podpisująca. Jeśli znasz klucz publiczny sygnatariusza, możesz sprawdzić, czy hash rzeczywiście pochodzi od sygnatariusza, a tym samym czy dane / plik rzeczywiście pochodzi od sygnatariusza (i jest niezmieniony). Te same klucze publiczne dla niektórych plików w GAC oznaczają „wszystkie podpisane przez tego samego sygnatariusza”.

Token klucza publicznego jest nieco czytelnym fragmentem prawdziwego klucza publicznego. Kompletny klucz publiczny jest przechowywany w podpisanym zestawie i służy do odszyfrowania podpisu (= zaszyfrowany skrót). Program ładujący używa tego do sprawdzenia, czy zawartość nie została zmieniona (lub uszkodzona). Oryginalny hash został zaszyfrowany przez autora przy użyciu klucza prywatnego i tylko osoba będąca w posiadaniu tego klucza może złożyć prawidłowy podpis.

Każda firma (lub dział) powinna używać tylko 1 pary kluczy, dlatego w GAC widzisz grupy identycznych PKT.

Chciałbym dodać do poprzednich odpowiedzi (szczególnie do tej z cytatem z Wikipedii), że silne nazewnictwo za pomocą klucza publicznego / prywatnego nie chroni przed uzyskaniem zmienionego zestawu ani nie uniemożliwia komuś ingerencji w twoje zestawy.

Po pierwsze , silna nazwa nie gwarantuje, że można zaufać zestawowi. Masz tylko klucz publiczny / token klucza publicznego, ale nie znasz osoby, która go podpisała (chyba że w jakiś sposób ogłosi, że jest właścicielem klucza publicznego zestawu).

Na przykład haker może zabrać twój zespół, usunąć z niego silną nazwę (są narzędzia, które to robią) i podpisać go własną silną nazwą. W przypadku zaufania istnieje inny rodzaj cyfrowego podpisu kodu za pomocą certyfikatu. Obejmuje sprawdzenie przez stronę trzecią Ciebie i Twojej firmy i nie jest bezpłatne. Sprawdź technologię Authenticode:

https://msdn.microsoft.com/en-us/library/ms537359(v=vs.85).aspx

Po drugie , w poniższej dyskusji krótko opisano metodę ataku brute force w celu uzyskania pary kluczy publiczny / prywatny z tym samym tokenem klucza publicznego, który wygenerowałby ten sam skrót dla zestawu po naruszeniu:

https://groups.google.com/forum/?hl=en#!topic/microsoft.public.dotnet.security/Jo6PqypxJN8

Muszę zauważyć, że można było rozwiązać ten problem przez ulepszone silne nazewnictwo https://docs.microsoft.com/en-us/dotnet/framework/app-domains/enhanced-strong-naming

W dyskusji wspomniano również o błędzie, który pozwolił pominąć sprawdzanie poprawności zestawu i załadować zmodyfikowany zestaw w czasie wykonywania. Szczegółowe badania są tutaj, błąd został naprawiony w późniejszych wersjach .Net frameworka (więc błąd obecny w starym .Net 1):

http://www.grimes.nildram.co.uk/workshops/fusionWSCrackThree.htm

Po trzecie , uruchamianie .Net 3.5 sp1 w celu zwiększenia wydajności obciążenia zestawów nie jest domyślnie sprawdzane w przypadku zestawów z pełnym zaufaniem.

https://docs.microsoft.com/en-us/dotnet/framework/app-domains/how-to-disable-the-strong-name-bypass-feature

Warunek dla zespołów: https://blogs.msdn.microsoft.com/shawnfa/2008/05/14/strong-name-bypass/

Dyskusja na ten temat w Stack Overflow: Czy podpisane zestawy .net są kiedykolwiek w pełni weryfikowane po załadowaniu, aby sprawdzić, czy nie zostały zmodyfikowane?

Jak rozumiem oznacza to, że montaż nie jest hashowany podczas ładowania aby sprawdzić czy tak

Na koniec chciałbym wspomnieć, że toczy się debata na temat zalet i wad silnego nazewnictwa, ponieważ wymagają one określenia wersji zestawu. Microsoft usuwa silną nazwę z niektórych swoich produktów: https://www.pedrolamas.com/2016/03/01/still-strong-naming-your-assemblies-you-do-know-its-2016-right/

Podsumowując, Chciałem podsumować wszystkie wymienione punkty. Kiedy napotkałem silne nazewnictwo, pomyliły mnie MSDN i Wikipedia, że ​​może to zapewnić jakąś ochronę dla zgromadzeń. Pomyślałem „Cool” i mocne nazewnictwo pozostało w mojej pamięci jako mechanizm ochronny. Do tej pory musiałem pomyśleć o bezpieczeństwie mojego pliku SNK z kluczem prywatnym i wtedy mój kolega powiedział mi, że nie jest taki „fajny”. Zrobiłem więc trochę badań. Pierwszą rzeczą, której się nauczyłem, było to, że silna nazwa nie oznacza zaufania, powinieneś użyć do tego certyfikatu. Mimo to pomyślałem, że jeśli zachowam klucz prywatny w bezpiecznym miejscu, to zmodyfikowany zestaw nie zostanie przeze mnie podpisany, co oznacza, że ​​jeśli ktoś zmodyfikuje mój zestaw, to również musi zmodyfikować znak, a zmodyfikowany zestaw nie zostanie załadowany przez CLR. Teraz nie Myślę, że silne nazewnictwo to gwarantuje. Dlatego należy na nim polegać tylko po to, aby zagwarantować niepowtarzalność montażu.

PS. Przepraszamy za długi post z wieloma odniesieniami.