Podepisování kódu - Code signing

Podepisování kódu je proces digitálního podepisování spustitelných souborů a skriptů za účelem potvrzení autora softwaru a záruky, že kód nebyl od podpisu změněn nebo poškozen. Tento proces využívá kryptografický hash k ověření pravosti a integrity.

Podepisování kódu může poskytnout několik cenných funkcí. Nejběžnějším použitím podepisování kódu je zajištění zabezpečení při nasazení; v některých programovacích jazycích jej lze také použít k prevenci konfliktů oboru názvů. Téměř každá implementace podepisování kódu poskytne nějaký druh mechanismu digitálního podpisu k ověření identity autora nebo systému sestavení a kontrolní součet k ověření, že objekt nebyl změněn. Lze jej také použít k poskytnutí informací o verzi o objektu nebo k uložení dalších metadat o objektu.

Účinnost podepisování kódu jako ověřovacího mechanismu pro software závisí na zabezpečení podepisování podpisových klíčů. Stejně jako u jiných technologií infrastruktury veřejných klíčů (PKI) integrita systému závisí na tom, že vydavatelé zabezpečují své soukromé klíče před neoprávněným přístupem. Klíče uložené v softwaru na počítačích pro všeobecné použití jsou náchylné ke kompromitaci. Proto je bezpečnější a nejlepší postup ukládat klíče do zabezpečených kryptografických hardwarových zařízení odolných proti neoprávněné manipulaci, známých jako moduly zabezpečení hardwaru nebo HSM .

Poskytování zabezpečení

Mnoho implementací podepisování kódu poskytne způsob, jak podepsat kód pomocí systému zahrnujícího dvojici klíčů, jeden veřejný a jeden soukromý, podobný procesu používanému TLS nebo SSH . Například v případě .NET používá vývojář soukromý klíč k podpisu svých knihoven nebo spustitelných souborů při každém jejich sestavení. Tento klíč bude jedinečný pro vývojáře nebo skupinu nebo někdy pro aplikaci nebo objekt. Vývojář může tento klíč buď vygenerovat samostatně, nebo jej získat od důvěryhodné certifikační autority (CA).

Podepisování kódu je zvláště cenné v distribuovaných prostředích, kde nemusí být zdroj daného kusu kódu okamžitě zřejmý - například aplety Java , ovládací prvky ActiveX a další aktivní skriptovací kód pro web a prohlížeč. Dalším důležitým využitím je bezpečné poskytování aktualizací a oprav stávajícího softwaru. Windows , Mac OS X a většina distribucí Linuxu poskytují aktualizace pomocí podepisování kódu, aby bylo zajištěno, že ostatní nebudou moci zlomyslně distribuovat kód prostřednictvím opravného systému. Umožňuje přijímajícímu operačnímu systému ověřit, zda je aktualizace legitimní, i když byla aktualizace doručena třetími stranami nebo fyzickými médii (disky).

Podepisování kódu se v systému Windows a Mac OS X používá k autentizaci softwaru při prvním spuštění a zajišťuje, že software nebyl zlomyslně manipulován distributorem třetí strany nebo webem pro stahování. Tato forma podepisování kódu se v Linuxu nepoužívá kvůli decentralizované povaze této platformy, přičemž správcem balíčků je převládající způsob distribuce všech forem softwaru (nejen aktualizací a záplat), jakož i open-source model umožňující přímou kontrolu v případě potřeby zdrojového kódu. Distribuce Linuxu založené na Debianu (mimo jiné) ověřují stažené balíčky pomocí kryptografie s veřejným klíčem.

Důvěryhodná identifikace pomocí certifikační autority (CA)

Veřejný klíč slouží k ověřování podpisu kódu by měly být sledovatelné zpět na důvěryhodnou kořenovou autoritou CA, pokud možno s použitím zabezpečené infrastruktury veřejného klíče (PKI). To nezajišťuje důvěryhodnost samotného kódu, pouze to, že pochází z uvedeného zdroje (nebo přesněji z konkrétního soukromého klíče ). Certifikační úřad poskytuje kořenovou úroveň důvěryhodnosti a je schopen přiřadit důvěru ostatním prostřednictvím serveru proxy. Pokud uživatel důvěřuje certifikační autoritě, pak může pravděpodobně věřit legitimitě kódu, který je podepsán klíčem vygenerovaným danou certifikační autoritou nebo jedním z jejích zástupců. Mnoho operačních systémů a rámců obsahuje integrovanou důvěryhodnost pro jednu nebo více certifikačních autorit. Je také běžné, že velké organizace implementují soukromou certifikační autoritu, interní v organizaci, která poskytuje stejné funkce jako veřejné certifikační autority, ale je důvěryhodná pouze v rámci organizace.

Podepisování kódu s rozšířenou validací (EV)

Certifikáty podpisu kódu s prodlouženou validací (EV) podléhají dalším ověřovacím a technickým požadavkům. Tyto pokyny vycházejí ze základních požadavků a rozšířených pokynů pro validaci fóra CA/B. Kromě požadavků na ověření specifických pro EV, pokyny pro podepisování kódu EV stanoví, že „soukromý klíč účastníka je generován, uložen a používán v krypto modulu, který splňuje nebo překračuje požadavky FIPS 140-2 úrovně 2“.

Některé aplikace, jako například podepisování ovladačů režimu jádra Windows 10, vyžadují certifikát pro podpis kódu EV. IEBlog společnosti Microsoft navíc uvádí, že programy pro Windows „podepsané certifikátem pro podpis kódu EV mohou okamžitě zajistit pověst služeb reputace SmartScreen, i když pro tento soubor nebo vydavatele neexistuje žádná předchozí pověst“.

Ukázka certifikátu podpisu EV kódu

Toto je příklad dekódovaného certifikátu pro podpis kódu EV, který používá SSL.com k podepisování softwaru. SSL.com EV Code Signing Intermediate CA RSA R3je zobrazen jako commonName emitenta a identifikuje to jako certifikát pro podpis kódu EV. Pole certifikátu Subjectpopisuje SSL Corp jako organizaci. Code Signingje zobrazen jako jediné rozšířené použití klíče X509v3.

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 ...

Alternativa k CA

Druhým modelem je model důvěryhodnosti při prvním použití , ve kterém se vývojáři mohou rozhodnout poskytnout svůj vlastní generovaný klíč. V tomto scénáři by uživatel normálně musel nějakým způsobem získat veřejný klíč přímo od vývojáře, aby ověřil, že je objekt poprvé od něj. Mnoho systémů pro podepisování kódu uloží veřejný klíč do podpisu. Některé softwarové rámce a operační systémy, které před spuštěním kontrolují podpis kódu, vám po prvním spuštění umožní rozhodnout se, že tomuto vývojáři důvěřujete. Vývojář aplikace může poskytnout podobný systém zahrnutím veřejných klíčů do instalačního programu. Klíč pak lze použít k zajištění toho, aby všechny další objekty, které je třeba spustit, jako jsou upgrady, pluginy nebo jiná aplikace, byly všechny ověřeny jako pocházející od stejného vývojáře.

Časové razítko

Časové razítko bylo navrženo tak, aby obcházelo varování o důvěryhodnosti, které se objeví v případě vypršení platnosti certifikátu. Ve skutečnosti časové razítko prodlužuje důvěryhodnost kódu mimo dobu platnosti certifikátu.

V případě, že bude nutné certifikát z důvodu kompromitace odvolat, stane se součástí záznamu o odvolání konkrétní datum a čas kompromitující události. V tomto případě časové razítko pomáhá určit, zda byl kód podepsán před nebo po kompromitaci certifikátu.

Podepisování kódu v Xcode

Vývojáři musí své aplikace pro iOS a tvOS podepsat před spuštěním na jakémkoli skutečném zařízení a před jejich nahráním do App Store . To je nutné k prokázání, že vývojář vlastní platné ID vývojáře Apple. Aby aplikace mohla běžet na zařízeních, potřebuje platný profil nebo certifikát.

Problémy

Jako každé bezpečnostní opatření lze podepisování kódu porazit. Uživatelé mohou být podvedeni, aby spustili nepodepsaný kód, nebo dokonce spustili kód, který odmítá ověřit, a systém zůstane zabezpečený pouze za předpokladu, že soukromý klíč zůstane soukromý.

Je také důležité si uvědomit, že podepisování kódu nechrání koncového uživatele před žádnou škodlivou aktivitou nebo neúmyslnými chybami softwaru od autora softwaru - pouze zajišťuje, že software nebyl upraven nikým jiným než autorem. Sandboxové systémy někdy nepřijímají certifikáty kvůli falešnému časovému razítku nebo kvůli nadměrnému využití RAM .

Implementace

Společnost Microsoft implementuje formu podpisu kódu (na základě Authenticode) poskytovanou pro ovladače testované společností Microsoft. Protože ovladače běží v jádře, mohou destabilizovat systém nebo otevřít systém do bezpečnostních děr. Z tohoto důvodu Microsoft testuje ovladače odeslané do svého programu WHQL . Poté, co ovladač prošel, společnost Microsoft podepíše tuto verzi ovladače jako bezpečnou. Pouze na 32bitových systémech je instalace ovladačů, které nejsou ověřeny společností Microsoft, možná po odsouhlasení povolení instalace na výzvu s upozorněním uživatele, že kód není podepsán. Pro kód .NET (spravovaný) existuje další mechanismus nazvaný Strong Name Signing, který používá veřejné/soukromé klíče a SHA -1 hash na rozdíl od certifikátů. Microsoft však odrazuje od spoléhání na Strong Name Signing jako náhradu za Authenticode.

Nepodepsaný kód v herních a spotřebitelských zařízeních

V kontextu spotřebitelských zařízení, jako jsou herní konzole , se termín „nepodepsaný kód“ často používá k označení aplikace, která nebyla podepsána kryptografickým klíčem, který je normálně vyžadován pro přijetí a spuštění softwaru. Většina her pro konzoly musí být podepsána tajným klíčem navrženým výrobcem konzoly, jinak se hra do konzoly nenačte. Existuje několik způsobů, jak spustit nesignovaný kód, které zahrnují softwarové exploity , použití modchipu , techniku ​​známou jako swapový trik nebo spuštění softmod .

Zpočátku se nemusí zdát zřejmé, proč pouhé zkopírování podepsané aplikace na jiné DVD neumožňuje její spuštění. Na konzoli Xbox je důvodem to, že spustitelný soubor Xbox (XBE) obsahuje příznak typu média, který určuje typ média, ze kterého je XBE spouštěno. U téměř veškerého softwaru Xbox je toto nastaveno tak, že spustitelný soubor se spustí pouze z disků vyrobených ve výrobě, takže k zastavení provádění softwaru stačí prosté zkopírování spustitelného média na vypalovatelné médium.

Protože je však spustitelný soubor podepsán, není jednoduchá změna hodnoty příznaku možná, protože to změní podpis spustitelného souboru, což způsobí, že při kontrole selže ověření.

Viz také

Reference

externí odkazy