Czym jest “Delayed signing”?

W ostatnim poście napisałem kiedy warto korzystać z strong-name. Jeśli ktoś uważnie prześledził screen’y dołączone do postu, być może dostrzegł, że jest tam opcja taka jak “Delayed Signing”. Do czego to służy?

Sprawa jest bardzo prosta. Delayed signing po prostu nie używa klucza prywatnego. Taka biblioteka nie zawiera więc poprawnego podpisu cyfrowego a w miejsce jego zawiera same zera. Klucz publiczny z kolei jest wstawiany do biblioteki z tym, że nie jest liczony jej hash. Integralność zatem jest niemożliwa (brak hash’u) jak również prawidłowa autoryzacja biblioteka (brak podpisu). Po za tym, biblioteka zachowuje się jak SN więc możliwe jest umieszczenie jej w GAC’u.

Po co nam biblioteka bez podpisu cyfrowego? W dużych organizacjach dostęp do klucza prywatnego ma wyłącznie klika osób. Programiści nie mają dostępu do niego na swoich maszynach deweloperskich. Podpisanie biblioteki odbywa się na osobnych maszynach przez osoby do tego powołane. Żaden z programistów nie może tego zrobić lokalnie na swoim komputerze – klucz prywatny musi być przechowywany w bezpiecznym miejscu. Programiści jednak muszą implementować a potem testować swoje rozwiązania. Jeśli wymagane jest użycie biblioteki SN nie ma sensu za każdym razem odsyłać ją  do osoby mającej potrzebne uprawnienia. Z tego względu programiści używają Delayed Signing w czasie implementacji a dopiero na końcu np. przed wydaniem lub fazą testowania produktu dokonywane jest podpisanie. Delayed signing zatem ma znaczenie wyłącznie dla programistów – jest to taka wersja “DEBUG” ułatwiająca prace nad kodem.

Jest jeszcze jeden mniej ważny powód dla którego Delayed signing może okazać się przydatne. Osoby korzystające z obfuscator’a nie mogą używać go na bibliotece już podpisanej. Jeśli odpalą obfuscator’a na takiej bibliotece wtedy oczywiście zostaną zmienione nazwy wszystkich zmiennych a to poskutkuje niepoprawną sumą kontrolną – po załadowaniu okaże się, że wyliczony hash jest inny niż ten zawarty w podpisie cyfrowym. W przypadku Delayed Signing można najpierw wygenerować bibliotekę SN, odpalić na niej obfuscator a na końcu ją podpisać.

Delayed signing można ustawić za pomocą zakładki signing znajdującej się we właściwościach projektu:

image

Niestety to nie wystarczy. Po uruchomieniu projektu lub próbie zainstalowania go w GAC dostaniemy następujący wyjątek:

“Could not load file or assembly ‘ClassLibrary1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=93b3674e817090ba’ or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)”

Oczywiście jest ro związane z faktem, że hash jest pusty (same zera) i naturalnie nie pokrywa to się z rzeczywistą sumą kontrolną. Z tego względu musimy powiadomić .NET Framework aby nie dokonywał on wspomnianej walidacji:

sn –Vr ClassLibrary1.dll
Polecenie tak naprawdę doda klucz rejestru do: HKEY_LOCAL_MACHINE\SOFTWARE.

Załóżmy, że implementacja została zakończona i kolejnym krokiem jest już podpisanie biblioteki za pomocą klucza prywatnego. Wtedy należy użyć następującego polecenia:

sn -R ClassLibrary.dll sgKey.snk

Po tym biblioteka zostanie już w pełni SN – z sumą kontrolką i podpisem cyfrowym. Warto jednak na zakończenie usunąć bibliotekę z rejestru plików nie sprawdzanych pod kątem integralności:

SN –Vu ClassLibrary.dll

Należy uważać na sn  – Vr ponieważ wiąże się z tym ryzyko – w końcu podpis cyfrowy jest nie sprawdzany i ktoś mógłby podmienić bibliotekę na inną, zawierającą złośliwy kod.

2 thoughts on “Czym jest “Delayed signing”?”

Leave a Reply

Your email address will not be published.