Gå til indhold
atlas

Kodesignering

Også kendt som: softwaresignering

At sætte en digital signatur på software, så brugere og systemer kan tjekke, hvem der har lavet den, og at ingen har ændret den bagefter.

Kladde - dette opslag er endnu ikke gennemgået.

Formelt

Udgiveren beregner en hash af et program, en opdatering, et script eller et container-image og signerer den med en privat nøgle knyttet til et digitalt certifikat; før systemet installerer eller kører filen, tjekker det signaturen og certifikatet og afviser filen, hvis noget ikke stemmer.

Forklaret enkelt

Som forseglingen på et medicinglas med producentens navn - er forseglingen brudt eller navnet forkert, sluger man ikke indholdet.

I praksis

En kommunes IT-drift lader kun medarbejdernes computere køre software, der er signeret af godkendte udgivere; da en falsk “opdatering” kommer ind med en mail, nægter Windows at starte den, fordi signaturen mangler.

Hvorfor det betyder noget

Angribere gemmer ofte malware i opdateringer, der ser ægte ud; et signaturtjek stopper enhver fil, der er ændret efter signeringen, men hjælper ikke, hvis selve signeringsnøglen bliver stjålet.

Sådan kommer du i gang

De typiske trin i rækkefølge. Tilpas dem til jeres organisation.

  1. List alt, hvad I udgiver eller kører, som kan signeres - installationsfiler, programmer, scripts, pakker, container-images og udgivelsesfiler - og beslut, hvilke der skal signeres.
  2. Vælg signeringsmetode pr. platform, fx Authenticode til Windows, codesign med notarisering til Apple, Sigstore cosign eller Notation til container-images og pakkehåndteringens egen signering til pakker.
  3. Generér og opbevar private signeringsnøgler i en HSM eller en nøgletjeneste i skyen (et krav for offentligt betroede kodesigneringscertifikater siden 1. juni 2023), eller brug nøgleløs Sigstore-signering knyttet til CI-workflowets identitet.
  4. Signér kun i en hærdet frigivelsespipeline, aldrig på udvikleres maskiner, og kræv separat godkendelse af hver signering af en produktionsudgivelse.
  5. Tilføj et tidsstempel efter RFC 3161 til hver signatur, så den forbliver gyldig, efter certifikatet er udløbet, og planlæg fornyelse, da offentligt betroede certifikater siden 1. marts 2026 højst må gælde i 460 dage.
  6. Udgiv build-provenance (SLSA) og en SBOM sammen med det signerede artefakt, så modtagerne kan se, hvordan og af hvad det er bygget.
  7. Håndhæv verifikation dér, hvor koden kører - App Control for Business eller AppLocker på Windows, Gatekeeper på macOS, signaturtjek i pakkehåndteringen og en admission controller i Kubernetes, der afviser usignerede images eller en uventet underskriver.
  8. Skriv og øv en procedure for en stjålet nøgle - tilbagekald certifikatet med en invalidity date, signér berørte udgivelser igen med en ny nøgle, og informér kunderne.

Typiske faldgruber

  • At tage en gyldig signatur som bevis for, at koden er sikker, selv om et kompromitteret byggesystem signerer ondsindet kode lige så gyldigt.
  • At opbevare signeringsnøgler som filer på byggeservere eller bærbare, hvor malware kan kopiere dem.
  • At signere alt, men aldrig tjekke signaturer dér, hvor softwaren installeres eller kører.
  • Kun at tjekke, at en Sigstore-signatur findes, uden at kontrollere den forventede underskriveridentitet og udsteder.

Gode vejledninger

Teknisk uddybning

Alle ordninger for kodesignering lægger en digital signatur over et digest af artefaktet, men formaterne varierer efter platform. Microsoft Authenticode (introduceret 1996) indlejrer en PKCS#7/CMS SignedData-struktur i PE-filens certifikattabel og hasher filen, idet checksummen og selve signaturområdet udelades; Apples codesign gemmer et code directory med hashes per side og kræver notarisering for Gatekeeper; Java signerer JAR-manifester; Linux-distributioner signerer repository-metadata eller pakker med OpenPGP-nøgler; Android bruger APK Signature Scheme v2 og senere, som dækker hele arkivet. Underskriverens X.509-certifikat skal have extended key usage codeSigning (OID 1.3.6.1.5.5.7.3.3) og kæde op til en rod i verifikatorens tillidslager.

Tidsstempling løser problemet med udløb. Signaturen sendes til en Time-Stamping Authority efter RFC 3161, som kontrasignerer signaturens hash med et betroet tidspunkt; verifikatorer accepterer så signaturen, efter certifikatet er udløbet, så længe det var gyldigt på tidsstemplet. Det påvirker også tilbagekaldelse: bliver en nøgle kompromitteret, kan CA'en tilbagekalde med en invalidity date, så kun signaturer tidsstemplet efter kompromitteringen fejler. Offentligt betroede kodesigneringscertifikater er underlagt CA/Browser Forums Code Signing Baseline Requirements, der siden 1. juni 2023 kræver, at abonnentens private nøgle genereres og opbevares i et hardwarebaseret kryptomodul (HSM, token eller HSM-tjeneste i skyen), og som siden 1. marts 2026 begrænser certifikaters gyldighed til 460 dage.

Sigstore, et OpenSSF-projekt, tilbyder "nøgleløs" signering rettet mod open source- og container-forsyningskæder: cosign henter et OIDC-token for underskriverens identitet (en persons e-mail eller en CI-workflows identitet), Fulcio udsteder et certifikat til en flygtig nøgle, der er gyldigt i omkring ti minutter, signaturen og certifikatet registreres i transparensloggen Rekor, og verifikatorer tjekker både den forventede identitet og udsteder og optagelsen i loggen. Notary Projects notation er et PKI-baseret alternativ til OCI-artefakter; npm, PyPI og Maven Central har i forskellige former indført Sigstore-baseret provenance eller signaturer.

Den vigtigste begrænsning er, at en signatur bevidner, hvem der signerede, ikke hvad koden gør. Stjålne nøgler har signeret malware (Stuxnet brugte certifikater stjålet fra Realtek og JMicron), og kompromitterede byggesystemer giver fuldt gyldige signaturer på ondsindet kode, som med SolarWinds Orion i 2020 og 3CX' desktopklient i 2023. Effektive programmer beskytter derfor nøgler i HSM'er med separat godkendelse af hver signering, signerer kun i hærdede frigivelsespipelines frem for på udvikleres maskiner, kobler signaturer med build-provenance (SLSA) og SBOM'er og håndhæver verifikation hos modtageren: Windows Defender Application Control- eller AppLocker-politikker, macOS Gatekeeper, pakkehåndteringens signaturtjek og admission controllers i Kubernetes, der afviser usignerede images.

Hvad du bør lære først

Alt det, dette bygger på - grundlaget først.

  1. Kryptografisk nøgle
  2. →Hashing
  3. →Digital identitet
  4. →Asymmetrisk kryptografi (public key)
  5. →Digital signatur
  6. →Digitalt certifikat
  7. →Kodesignering

Relationer

Kilder og videre læsning

Standarder og officielle tekster

Officiel dokumentation

Hvor dataene kommer fra

Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.

Se gennemgangskøenForeslå en rettelse på GitHubDette begreb som JSON

Test dig selv

Indlæser…

Atlas er i beta.