Koodin allekirjoitus - Code signing

Koodin allekirjoittaminen on prosessi, jossa allekirjoitetaan suoritettavat tiedostot ja komentosarjat digitaalisesti ohjelmiston tekijän vahvistamiseksi ja taataan, että koodia ei ole muutettu tai vioittunut sen allekirjoittamisen jälkeen. Prosessi työllistää käyttö salaus hash vahvistaa aitouden ja eheyden.

Koodin allekirjoittaminen voi tarjota useita arvokkaita ominaisuuksia. Yleisin koodin allekirjoituksen käyttö on turvallisuuden tarjoaminen käyttöönotossa; joillakin ohjelmointikielillä sitä voidaan käyttää myös nimitilan ristiriitojen estämiseen. Lähes jokainen koodin allekirjoituksen toteutus tarjoaa jonkinlaisen digitaalisen allekirjoitusmekanismin tekijän tai koontijärjestelmän henkilöllisyyden tarkistamiseksi ja tarkistussumman sen varmistamiseksi, että objektia ei ole muutettu. Sitä voidaan käyttää myös esineiden versiotietojen antamiseen tai objektin muiden metatietojen tallentamiseen.

Koodin allekirjoittamisen tehokkuus ohjelmiston todennusmekanismina riippuu allekirjoitusavainten tukemisesta. Kuten muutkin julkisen avaimen infrastruktuuritekniikat (PKI) , järjestelmän eheys riippuu julkaisijoista, jotka suojaavat yksityiset avaimensa luvattomalta käytöltä. Yleiskäyttöisten tietokoneiden ohjelmistoihin tallennetut avaimet ovat alttiita vaarantumiselle. Siksi on turvallisempaa ja paras käytäntö säilyttää avaimet turvallisissa, väärentämisen estävissä salauslaitteissa, jotka tunnetaan laitteiston suojausmoduuleina tai HSM-laitteina .

Turvallisuuden tarjoaminen

Monet koodin allekirjoitusratkaisut tarjoavat tavan allekirjoittaa koodi käyttäen järjestelmää, johon kuuluu avainpari, yksi julkinen ja yksi yksityinen, samanlainen kuin TLS: n tai SSH: n käyttämä prosessi . Esimerkiksi .NET: n tapauksessa kehittäjä allekirjoittaa kirjastonsa tai suoritettavat tiedostot yksityisellä avaimella joka kerta, kun ne rakennetaan. Tämä avain on ainutlaatuinen kehittäjälle tai ryhmälle tai joskus sovellukselle tai objektille. Kehittäjä voi joko luoda tämän avaimen itse tai hankkia sen luotetulta varmentajalta (CA).

Koodin allekirjoittaminen on erityisen arvokasta hajautetussa ympäristössä, jossa tietyn koodin lähde ei välttämättä ole heti selvä - esimerkiksi Java -sovelmia , ActiveX -komponentteja ja muuta aktiivista verkko- ja selainkomentokoodia. Toinen tärkeä käyttötarkoitus on päivitysten ja korjausten toimittaminen turvallisesti olemassa oleville ohjelmistoille. Windows , Mac OS X ja useimmat Linux -jakelut tarjoavat päivityksiä koodin allekirjoituksella, jotta muut eivät voi jakaa koodia haitallisesti korjausjärjestelmän kautta. Sen avulla vastaanottava käyttöjärjestelmä voi tarkistaa päivityksen laillisuuden, vaikka päivitys olisi toimitettu kolmansien osapuolten tai fyysisen tallennusvälineen (levyjen) kautta.

Koodin allekirjoitusta käytetään Windows- ja Mac OS X -käyttöjärjestelmissä ohjelmiston todentamiseen ensimmäisellä käyttökerralla varmistaen, ettei kolmannen osapuolen jakelija tai lataussivusto ole peukaloinut ohjelmistoa haitallisesti. Tätä koodin allekirjoitusmuotoa ei käytetä Linuxissa sen alustan hajautetun luonteen vuoksi, koska pakettienhallinta on vallitseva jakelutapa kaikentyyppisille ohjelmistoille (ei vain päivityksille ja korjauksille), sekä avoimen lähdekoodin malli, joka mahdollistaa suoran tarkastuksen lähdekoodista haluttaessa. Debian -pohjaiset Linux -jakelut (mm.) Vahvistavat ladatut paketit julkisen avaimen salauksella.

Luotettu tunnistus varmenneviranomaisen (CA) avulla

Julkisen avaimen , jota käytetään todennukseen koodin allekirjoitus on voitava jäljittää takaisin luotettu root CA, edullisesti käyttämällä suojattua julkisen avaimen infrastruktuuri (PKI). Tämä ei takaa, että itse koodiin voidaan luottaa, vain että se tulee ilmoitetusta lähteestä (tai tarkemmin sanottuna tietystä yksityisestä avaimesta ). Varmentaja antaa luottamuksen juuritasolle ja voi antaa luottamuksen muille välityspalvelimella. Jos käyttäjä luottaa varmentajaan, käyttäjä voi olettaa luottavansa koodin laillisuuteen, joka on allekirjoitettu kyseisen varmentajan tai jonkin sen välityspalvelimen luomalla avaimella. Monet käyttöjärjestelmät ja -kehykset sisältävät sisäänrakennetun luottamuksen yhdelle tai useammalle varmentajalle. On myös tavallista, että suuret organisaatiot ottavat käyttöön organisaation sisäisen yksityisen varmentajan, joka tarjoaa samat ominaisuudet kuin julkiset varmentajat, mutta siihen luotetaan vain organisaation sisällä.

Laajennettu validointi (EV) -koodin allekirjoitus

Laajennetun validoinnin (EV) koodin allekirjoitusvarmenteisiin sovelletaan lisävahvistusta ja teknisiä vaatimuksia. Nämä ohjeet perustuvat CA/B -foorumin perusvaatimuksiin ja laajennettuihin validointiohjeisiin. EV: tä koskevien validointivaatimusten lisäksi EV-koodin allekirjoitusohjeissa määrätään, että "tilaajan yksityinen avain luodaan, tallennetaan ja käytetään salausmoduulissa, joka täyttää tai ylittää FIPS 140-2 -tason 2 vaatimukset".

Tietyt sovellukset, kuten Windows 10 -ydinohjaimen allekirjoittaminen, edellyttävät EV-koodin allekirjoitusvarmennetta. Lisäksi Microsoftin IEBlogin mukaan Windows -ohjelmat, "jotka on allekirjoitettu EV -koodin allekirjoitusvarmenteella, voivat heti luoda maineen SmartScreen -mainepalveluiden kanssa, vaikka kyseisellä tiedostolla tai julkaisijalla ei olisi aiempaa mainetta".

Esimerkki EV -koodin allekirjoitusvarmenteesta

Tämä on esimerkki dekoodatusta EV -koodin allekirjoitusvarmenteesta, jota SSL.com käyttää ohjelmiston allekirjoittamiseen. SSL.com EV Code Signing Intermediate CA RSA R3näkyy liikkeeseenlaskijan commonName -nimellä, joka tunnistaa sen EV -koodin allekirjoitusvarmenteeksi. Varmenteen Subjectkentässä SSL Corp on organisaatio. Code Signingnäkyy ainoana X509v3 laajennetussa avainkäytössä. 

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

Vaihtoehto CA: lle

Toinen malli on luottamus ensimmäiseen käyttöön -mallissa, jossa kehittäjät voivat halutessaan antaa oman itse luomansa avaimen. Tässä skenaariossa käyttäjän on tavallisesti hankittava julkinen avain jollain tavalla suoraan kehittäjältä varmistaakseen, että objekti on häneltä ensimmäistä kertaa. Monet koodin allekirjoitusjärjestelmät tallentavat julkisen avaimen allekirjoituksen sisälle. Jotkin ohjelmistokehykset ja käyttöjärjestelmät, jotka tarkistavat koodin allekirjoituksen ennen sen suorittamista, antavat sinun valita luottaa kyseiseen kehittäjään siitä hetkestä lähtien ensimmäisen ajon jälkeen. Sovelluskehittäjä voi tarjota samanlaisen järjestelmän sisällyttämällä julkiset avaimet asentajan mukana. Avainta voidaan sitten käyttää sen varmistamiseen, että kaikki myöhemmät suoritettavat objektit, kuten päivitykset, laajennukset tai muu sovellus, on vahvistettu tulevan samalta kehittäjältä.

Aikaleimaus

Aikaleimaus on suunniteltu kiertämään luottamusvaroitus, joka tulee näkyviin, jos varmenne on vanhentunut. Itse asiassa aikaleimaus pidentää koodin luottamusta varmenteen voimassaoloajan jälkeen.

Jos varmenne on peruutettava kompromissin vuoksi, tietty päivämäärä ja kellonaika vaarantavasta tapahtumasta tulee osa peruutustietuetta. Tässä tapauksessa aikaleima auttaa selvittämään, onko koodi allekirjoitettu ennen varmenteen vaarantamista vai sen jälkeen.

Koodin allekirjoitus Xcodessa

Kehittäjien on allekirjoitettava iOS- ja tvOS -sovelluksensa ennen niiden käyttämistä millä tahansa oikealla laitteella ja ennen lataamista App Storeen . Tätä tarvitaan todistamaan, että kehittäjä omistaa voimassa olevan Apple -kehittäjätunnuksen. Sovellus tarvitsee kelvollisen profiilin tai varmenteen, jotta se voi toimia laitteilla.

Ongelmia

Kuten mikä tahansa turvatoimenpide, koodin allekirjoitus voidaan voittaa. Käyttäjiä voidaan huijata suorittamaan allekirjoittamaton koodi tai jopa suorittamaan koodi, joka kieltäytyy vahvistamasta, ja järjestelmä pysyy suojattuna vain niin kauan kuin yksityinen avain on yksityinen.

On myös tärkeää huomata, että koodin allekirjoittaminen ei suojaa loppukäyttäjää haittaohjelmilta tai tahattomilta ohjelmistovirheiltä ohjelmiston tekijän toimesta - se vain varmistaa, että kukaan muu kuin tekijä ei ole muokannut ohjelmistoa. Joskus hiekkalaatikkojärjestelmät eivät hyväksy varmenteita väärän aikaleiman tai RAM-muistin liiallisen käytön vuoksi .

Toteutukset

Microsoft toteuttaa eräänlaisen koodin allekirjoituksen (perustuu Authenticodeen) Microsoftin testatuille ohjaimille. Koska ohjaimet toimivat ytimessä, he voivat horjuttaa järjestelmän epävakautta tai avata järjestelmän suoja -aukkoihin. Tästä syystä Microsoft testaa WHQL -ohjelmaansa lähettämiä ohjaimia . Kun kuljettaja on ohittanut, Microsoft allekirjoittaa kyseisen ajuriversion turvalliseksi. Vain 32-bittisissä järjestelmissä ajureiden asentaminen, joita ei ole vahvistettu Microsoftin kanssa, on mahdollista sen jälkeen, kun olet hyväksynyt asennuksen sallimisen kehotettaessa käyttäjää varoittamaan koodista. .NET (hallittu) -koodille on lisämekanismi nimeltä Strong Name Signing, joka käyttää julkisia/yksityisiä avaimia ja SHA -1 -hajautusta varmenteiden sijaan. Microsoft ei kuitenkaan suostu luomaan vahvaa nimen allekirjoittamista Authenticoden korvaajaksi.

Allekirjoittamaton koodi peli- ja kuluttajalaitteissa

Kuluttajalaitteiden, kuten pelikonsoleiden , yhteydessä termiä "allekirjoittamaton koodi" käytetään usein viittaamaan sovellukseen, jota ei ole allekirjoitettu salausavaimella, jota tavallisesti tarvitaan ohjelmiston hyväksymiseen ja suorittamiseen. Useimmat konsolipelit on allekirjoitettava konsolin valmistajan salaisella avaimella, muuten peli ei lataudu konsoliin. Allekirjoittamattoman koodin saamiseksi suoritettavaksi on useita menetelmiä, joihin kuuluvat ohjelmistojen hyväksikäyttö , modchipin käyttö , swap -temppuna tunnettu tekniikka tai softmodin suorittaminen .

Aluksi ei ehkä näytä itsestään selvältä, miksi allekirjoitetun sovelluksen kopioiminen toiselle DVD -levylle ei salli sen käynnistymistä. On Xbox , syy tähän on se, että Xbox suoritettavaa tiedostoa (XBE) sisältää media-tyyppinen lippu, jossa määritetään median että XBE on käynnistyä. Lähes kaikissa Xbox-ohjelmistoissa tämä on asetettu siten, että suoritettava tiedosto käynnistyy vain tehtaalla valmistetuilta levyiltä, ​​joten yksinkertaisesti suoritettavan tiedoston kopioiminen polttavaan tietovälineeseen riittää pysäyttämään ohjelmiston.

Kuitenkin, koska suoritettava tiedosto on allekirjoitettu, lipun arvon yksinkertainen muuttaminen ei ole mahdollista, koska tämä muuttaa suoritettavan tiedoston allekirjoitusta, jolloin sen validointi epäonnistuu tarkistettaessa.

Katso myös

Viitteet

Ulkoiset linkit