Podpisywanie kodu - Code signing

Podpisywanie kodu to proces cyfrowego podpisywania plików wykonywalnych i skryptów w celu potwierdzenia autora oprogramowania i zagwarantowania, że ​​kod nie został zmieniony lub uszkodzony od czasu jego podpisania. Proces wykorzystuje hash kryptograficzny do weryfikacji autentyczności i integralności.

Podpisywanie kodu może zapewnić kilka cennych funkcji. Najczęstszym zastosowaniem podpisywania kodu jest zapewnienie bezpieczeństwa podczas wdrażania; w niektórych językach programowania może być również używany do zapobiegania konfliktom przestrzeni nazw. Prawie każda implementacja podpisywania kodu zapewni jakiś mechanizm podpisu cyfrowego w celu weryfikacji tożsamości autora lub systemu kompilacji oraz sumę kontrolną w celu sprawdzenia, czy obiekt nie został zmodyfikowany. Może być również używany do dostarczania informacji o wersji obiektu lub do przechowywania innych metadanych o obiekcie.

Skuteczność podpisywania kodu jako mechanizmu uwierzytelniania oprogramowania zależy od bezpieczeństwa podstawowych kluczy podpisywania. Podobnie jak w przypadku innych technologii infrastruktury klucza publicznego (PKI) , integralność systemu zależy od tego, czy wydawcy zabezpieczają swoje klucze prywatne przed nieautoryzowanym dostępem. Klucze przechowywane w oprogramowaniu na komputerach ogólnego przeznaczenia są podatne na zagrożenia. Dlatego bezpieczniej i zgodnie z najlepszą praktyką jest przechowywanie kluczy w bezpiecznych, odpornych na manipulacje urządzeniach kryptograficznych, znanych jako sprzętowe moduły zabezpieczeń lub moduły HSM .

Zapewnienie bezpieczeństwa

Wiele implementacji podpisywania kodu zapewnia sposób podpisywania kodu za pomocą systemu obejmującego parę kluczy, jeden publiczny i jeden prywatny, podobnie jak w procesie stosowanym przez TLS lub SSH . Na przykład w przypadku platformy .NET deweloper używa klucza prywatnego do podpisywania swoich bibliotek lub plików wykonywalnych za każdym razem, gdy budują. Ten klucz będzie unikalny dla programisty lub grupy, a czasami dla aplikacji lub obiektu. Deweloper może wygenerować ten klucz samodzielnie lub uzyskać go z zaufanego urzędu certyfikacji (CA).

Podpisywanie kodu jest szczególnie cenne w środowiskach rozproszonych, w których źródło danego fragmentu kodu może nie być od razu oczywiste – na przykład aplety Java , kontrolki ActiveX i inny aktywny kod skryptów internetowych i przeglądarek. Innym ważnym zastosowaniem jest bezpieczne dostarczanie aktualizacji i poprawek do istniejącego oprogramowania. Windows , Mac OS X i większość dystrybucji Linuksa udostępnia aktualizacje za pomocą podpisywania kodu, aby uniemożliwić innym złośliwe rozpowszechnianie kodu za pośrednictwem systemu poprawek. Umożliwia systemowi operacyjnemu odbierającemu sprawdzenie, czy aktualizacja jest legalna, nawet jeśli aktualizacja została dostarczona przez osoby trzecie lub nośniki fizyczne (dyski).

Podpisywanie kodu jest używane w systemach Windows i Mac OS X do uwierzytelniania oprogramowania przy pierwszym uruchomieniu , zapewniając, że oprogramowanie nie zostało złośliwie zmodyfikowane przez zewnętrznego dystrybutora lub witrynę pobierania. Ta forma podpisywania kodu nie jest używana w systemie Linux ze względu na zdecentralizowany charakter tej platformy, menedżer pakietów jest dominującym sposobem dystrybucji dla wszystkich form oprogramowania (nie tylko aktualizacji i poprawek), a także model open-source umożliwiający bezpośrednią inspekcję kodu źródłowego w razie potrzeby. Dystrybucje Linuksa oparte na Debianie (między innymi) weryfikują pobrane pakiety za pomocą kryptografii klucza publicznego.

Zaufana identyfikacja przy użyciu urzędu certyfikacji (CA)

Klucz publiczny używany do uwierzytelniania podpisu kod powinien być identyfikowalny z powrotem do zaufanego głównego urzędu, najlepiej przy użyciu bezpiecznej infrastruktury klucza publicznego (PKI). Nie gwarantuje to, że można ufać samemu kodowi, a jedynie, że pochodzi on z podanego źródła (lub bardziej wyraźnie, z określonego klucza prywatnego ). Urząd certyfikacji zapewnia główny poziom zaufania i może przypisywać zaufanie innym za pośrednictwem serwera proxy. Jeśli użytkownik ufa CA, to prawdopodobnie może ufać legalności kodu, który jest podpisany kluczem wygenerowanym przez ten CA lub jeden z jego serwerów proxy. Wiele systemów operacyjnych i struktur zawiera wbudowane zaufanie dla co najmniej jednego urzędu certyfikacji. W dużych organizacjach powszechne jest również wdrażanie prywatnego urzędu certyfikacji, wewnętrznego organizacji, który zapewnia te same funkcje, co publiczne urzędy certyfikacji, ale jest zaufany tylko w obrębie organizacji.

Podpisywanie kodu rozszerzonej walidacji (EV)

Certyfikaty podpisywania kodu rozszerzonej walidacji (EV) podlegają dodatkowym wymaganiom walidacyjnym i technicznym. Niniejsze wytyczne są oparte na podstawowych wymaganiach forum CA/B i rozszerzonych wytycznych dotyczących walidacji. Oprócz wymagań walidacji specyficznych dla EV, wytyczne dotyczące podpisywania kodu EV stanowią, że „klucz prywatny subskrybenta jest generowany, przechowywany i używany w module kryptograficznym, który spełnia lub przekracza wymagania FIPS 140-2 poziom 2”.

Niektóre aplikacje, takie jak podpisywanie sterowników trybu jądra systemu Windows 10, wymagają certyfikatu podpisywania kodu EV. Co więcej, Microsoft IEBlog stwierdza, że ​​programy Windows „podpisane certyfikatem podpisywania kodu EV mogą natychmiast ustalić reputację dzięki usługom reputacji SmartScreen , nawet jeśli nie istnieje wcześniejsza reputacja tego pliku lub wydawcy”.

Przykładowy certyfikat podpisywania kodu EV

Jest to przykład zdekodowanego certyfikatu podpisywania kodu EV używanego przez SSL.com do podpisywania oprogramowania. SSL.com EV Code Signing Intermediate CA RSA R3jest pokazany jako commonName emitenta, identyfikując go jako certyfikat podpisywania kodu EV. Pole certyfikatu Subjectopisuje SSL Corp jako organizację. Code Signingjest pokazane jako jedyne X509v3 Extended Key Usage.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            59:4e:2d:88:5a:2c:b0:1a:5e:d6:4c:7b:df:35:59:7d
    Signature Algorithm: sha256WithRSAEncryption
        Issuer:
            commonName                = SSL.com EV Code Signing Intermediate CA RSA R3
            organizationName          = SSL Corp
            localityName              = Houston
            stateOrProvinceName       = Texas
            countryName               = US
        Validity
            Not Before: Aug 30 20:29:13 2019 GMT
            Not After : Nov 12 20:29:13 2022 GMT
        Subject:
            1.3.6.1.4.1.311.60.2.1.3 = US
            1.3.6.1.4.1.311.60.2.1.2 = Nevada
            streetAddress             = 3100 Richmond Ave Ste 503
            businessCategory          = Private Organization
            postalCode                = 77098
            commonName                = SSL Corp
            serialNumber              = NV20081614243
            organizationName          = SSL Corp
            localityName              = Houston
            stateOrProvinceName       = Texas
            countryName               = US
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:c3:e9:ae:be:d7:a2:6f:2f:24 ...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                keyid:36:BD:49:FF:31:2C:EB:AF:6A:40:FE:99:C0:16:ED:BA:FC:48:DD:5F
                
            Authority Information Access: 
                CA Issuers - URI:http://www.ssl.com/repository/SSLcom-SubCA-EV-CodeSigning-RSA-4096-R3.crt
                OCSP - URI:http://ocsps.ssl.com
                
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.3
                Policy: 1.2.616.1.113527.2.5.1.7
                Policy: 1.3.6.1.4.1.38064.1.3.3.2
                  CPS: https://www.ssl.com/repository
                  
            X509v3 Extended Key Usage: 
                Code Signing
            X509v3 CRL Distribution Points: 
            
                Full Name:
                  URI:http://crls.ssl.com/SSLcom-SubCA-EV-CodeSigning-RSA-4096-R3.crl
                  
            X509v3 Subject Key Identifier: 
                EC:6A:64:06:26:A7:7A:69:E8:CC:06:D5:6F:FA:E1:C2:9A:29:79:DE
            X509v3 Key Usage: critical
                Digital Signature
    Signature Algorithm: sha256WithRSAEncryption
         17:d7:a1:26:58:31:14:2b:9f:3b ...

Alternatywa dla urzędów certyfikacji

Drugim modelem jest model zaufania przy pierwszym użyciu , w którym programiści mogą zdecydować się na dostarczenie własnego wygenerowanego klucza. W tym scenariuszu użytkownik normalnie musiałby w jakiś sposób uzyskać klucz publiczny bezpośrednio od dewelopera, aby po raz pierwszy zweryfikować, czy obiekt pochodzi od niego. Wiele systemów podpisywania kodu przechowuje klucz publiczny wewnątrz podpisu. Niektóre frameworki oprogramowania i systemy operacyjne, które sprawdzają podpis kodu przed wykonaniem, pozwolą Ci zaufać temu programiście od tego momentu po pierwszym uruchomieniu. Deweloper aplikacji może dostarczyć podobny system, dołączając klucze publiczne do instalatora. Klucz może być następnie użyty do zapewnienia, że ​​wszystkie kolejne obiekty, które muszą zostać uruchomione, takie jak aktualizacje, wtyczki lub inna aplikacja, są weryfikowane jako pochodzące od tego samego dewelopera.

Znacznik czasowy

Oznaczanie czasem zostało zaprojektowane w celu obejścia ostrzeżenia zaufania, które pojawi się w przypadku wygasłego certyfikatu. W efekcie znaczniki czasu wydłużają zaufanie do kodu poza okres ważności certyfikatu.

W przypadku, gdy certyfikat musi zostać unieważniony z powodu kompromitacji, konkretna data i godzina zdarzenia kompromitującego stanie się częścią rejestru unieważnień. W takim przypadku znaczniki czasu pomagają ustalić, czy kod został podpisany przed, czy po złamaniu certyfikatu.

Podpisywanie kodu w Xcode

Deweloperzy muszą podpisać swoje aplikacje iOS i tvOS przed uruchomieniem ich na jakimkolwiek rzeczywistym urządzeniu i przed przesłaniem ich do App Store . Jest to konieczne, aby udowodnić, że programista posiada ważny identyfikator Apple Developer ID. Aplikacja potrzebuje prawidłowego profilu lub certyfikatu, aby mogła działać na urządzeniach.

Problemy

Jak każdy środek bezpieczeństwa, podpisywanie kodu można pokonać. Użytkownicy mogą zostać nakłonieni do uruchomienia niepodpisanego kodu, a nawet do uruchomienia kodu, który odmawia weryfikacji, a system pozostaje bezpieczny tylko tak długo, jak klucz prywatny pozostaje prywatny.

Należy również zauważyć, że podpisywanie kodu nie chroni użytkownika końcowego przed jakąkolwiek złośliwą aktywnością lub niezamierzonymi błędami w oprogramowaniu ze strony autora oprogramowania — zapewnia jedynie, że oprogramowanie nie zostało zmodyfikowane przez nikogo poza autorem. Czasami systemy piaskownicy nie akceptują certyfikatów z powodu fałszywego znacznika czasu lub nadmiernego wykorzystania pamięci RAM .

Realizacje

Firma Microsoft implementuje formę podpisywania kodu (w oparciu o Authenticode) dostarczoną dla przetestowanych sterowników firmy Microsoft. Ponieważ sterowniki działają w jądrze, mogą zdestabilizować system lub otworzyć system na luki w zabezpieczeniach. Z tego powodu Microsoft testuje sterowniki przesłane do swojego programu WHQL . Po przejściu sterownika firma Microsoft podpisuje tę wersję sterownika jako bezpieczną. Tylko w systemach 32-bitowych instalowanie sterowników, które nie zostały zweryfikowane przez firmę Microsoft, jest możliwe po wyrażeniu zgody na instalację po wyświetleniu monitu ostrzegającego użytkownika, że ​​kod jest niepodpisany. W przypadku kodu platformy .NET (zarządzanego) istnieje dodatkowy mechanizm o nazwie podpisywanie silnej nazwy, który używa kluczy publicznych/prywatnych i skrótu SHA- 1 w przeciwieństwie do certyfikatów. Firma Microsoft odradza jednak poleganie na Silnym Podpisywanie Nazw jako zamienniku dla Authenticode.

Niepodpisany kod w grach i urządzeniach konsumenckich

W kontekście urządzeń konsumenckich, takich jak konsole do gier , termin „kod niepodpisany” jest często używany w odniesieniu do aplikacji, która nie została podpisana za pomocą klucza kryptograficznego zwykle wymaganego do akceptacji i uruchomienia oprogramowania. Większość gier konsolowych musi być podpisana tajnym kluczem zaprojektowanym przez producenta konsoli, w przeciwnym razie gra nie załaduje się na konsoli. Istnieje kilka metod uzyskania niepodpisanego kodu do wykonania, w tym exploity oprogramowania , użycie modchipa , techniki znanej jako sztuczka wymiany lub uruchomienie softmodu .

Na początku może nie wydawać się oczywiste, dlaczego zwykłe skopiowanie podpisanej aplikacji na inną płytę DVD nie pozwala na jej uruchomienie. Na konsoli Xbox powodem tego jest fakt, że plik wykonywalny Xbox (XBE) zawiera flagę typu nośnika, która określa typ nośnika, z którego można uruchomić XBE. W prawie każdym oprogramowaniu Xbox jest to ustawione tak, że plik wykonywalny będzie uruchamiał się tylko z dysków wyprodukowanych fabrycznie, więc wystarczy skopiować plik wykonywalny na nośnik do nagrywania, aby zatrzymać wykonywanie oprogramowania.

Jednak ponieważ plik wykonywalny jest podpisany, po prostu zmiana wartości flagi nie jest możliwa, ponieważ zmienia to podpis pliku wykonywalnego, powodując niepowodzenie sprawdzania poprawności podczas sprawdzania.

Zobacz też

Bibliografia

Zewnętrzne linki