Codeondertekening – een handleiding voor managers

Hoe is codeondertekening belangrijk geworden?

Laten we eens kijken naar drie interessante trends die de afgelopen tien jaar in softwareontwikkeling zijn ontstaan.

Ten eerste is het aantal bedrijven dat software ontwikkelt en uitbrengt enorm toegenomen. Een belangrijke aanleiding hiervoor is de smartphonerevolutie en de daarmee gepaard gaande behoefte van bedrijven aan eigen mobiele apps voor hun klanten, maar ook voor hun medewerkers.

De tweede trend is dat het primaire middel om software, en de bijbehorende patches en upgrades, te distribueren, nu alomtegenwoordig het internet is geworden. De voordelen van online softwaredistributie ten opzichte van traditionele methoden zoals cd's (compact discs) zijn aanzienlijk: grootschalige, vrijwel directe softwaredistributie tegen extreem lage kosten.

De derde trend is dat het aantal onafhankelijke softwareleveranciers (ISV's) die zich voornamelijk bezighouden met het bouwen van softwareapplicaties, de afgelopen jaren gestaag is toegenomen. Sommige onderzoeksrapporten laten zelfs een vertienvoudiging zien in de afgelopen tien jaar.

Deze trends verklaren hoe online softwaredistributie de voorkeursmethode is geworden voor bedrijven die software ontwikkelen en verkopen. Maar brengt deze methode, met zijn gemak en voordelen, ook bedrijfsrisico's met zich mee?

Hoe weet een gebruiker of de gedownloade software van de oorspronkelijke auteur afkomstig is (en niet van een imitator)? Hoe weet de gebruiker dat er niet met de software is geknoeid en dat er schadelijke code in de software is ingevoegd? Code ondertekening biedt het antwoord op deze vragen door bedrijven te helpen de software die zij uitbrengen te beveiligen.

Naast softwareontwikkelaars en beveiligingsspecialisten is het cruciaal dat projectmanagers, productmanagers, engineering managers en zelfs senior management bekend zijn met code signing. De reden is simpel. Code Signing is een uitstekende bescherming tegen malware-aanvallen. En malware is het duurste type aanval op een bedrijf: de gemiddelde kosten van een malware-aanval bedragen volgens een recent onderzoeksrapport van IBM Security $ 239 miljoen, wat 60 keer meer is dan de gemiddelde kosten van een datalek!

Hoe werkt codeondertekening?

Met ‘code’ in codeondertekening worden uitvoerbare bestanden, archieven, drivers, firmware, bibliotheken, pakketten en in principe alle software bedoeld die bedoeld is om te worden vrijgegeven en gedistribueerd naar een andere partij of gebruiker.

Om te begrijpen hoe codeondertekening werkt, is het belangrijk om een ​​basiskennis te hebben van Publieke Sleutel Infrastructuur (PKI)Zoals gedefinieerd in eerdere artikelen op deze blog, is PKI een set van rollen, beleidsregels, hardware, software en procedures die nodig zijn om digitale certificaten en het beheren van openbare-sleutelversleuteling. Het is ook belangrijk om de twee primaire doelen van codeondertekening te begrijpen:

1. Code-eigendom: Bewijzen dat de softwarecode die wordt gedownload en geïnstalleerd, afkomstig is van de oorspronkelijke, authentieke eigenaar.
2. Code-integriteit: Bewijzen dat er op geen enkele manier met de code is geknoeid of dat er wijzigingen in zijn aangebracht, bijvoorbeeld door er schadelijke code (malware) in te voegen.

Het proces van codeondertekening bestaat uit vier hoofdstappen, die hieronder worden beschreven.

1. Sleutel generatie: De basisvereiste voor codeondertekening is de beschikbaarheid van een privésleutel en de bijbehorende publieke sleutel. Het publieke en private sleutelpaar kan worden gegenereerd met behulp van een (vertrouwde) tool of software van derden. Een gedetailleerde uitleg over sleutelgeneratie valt buiten het bestek van dit artikel.
2. Codeondertekeningscertificaat: Vervolgens moet u een codeondertekeningscertificaat aanvragen met een Certificate Authority (CA), een vertrouwde entiteit die digitale certificaten uitgeeft. De aanvraag moet uw openbare sleutel bevatten, samen met andere identiteitsgegevens van de organisatie. Bekende CA's zijn onder andere Verisign, Digicert, Symantec, GoDaddy, Comodo, Let's Encrypt en GlobalSign. Het certificaat dat de CA uitgeeft, bevat informatie zoals uw (organisatie)identiteit, uw openbare sleutel, de geldigheidsduur van het certificaat, de digitale handtekening van de CA en andere details.
3. hashen: De volgende stap is het hashen van je code. Hashing is een eenrichtingsproces waarbij gegevens van elke grootte en elk type via een wiskundig algoritme kunnen worden omgezet naar gegevens met een vaste grootte. Het algoritme wordt een hashfunctie genoemd en de uitvoer, d.w.z. de gegevens met een vaste grootte, wordt een hashwaarde of hash genoemd. De hashwaarde verschilt volledig van de oorspronkelijke gegevens en de oorspronkelijke gegevens kunnen niet uit de hash worden afgeleid.
4. Ondertekening: De hashwaarde van de software wordt vervolgens versleuteld of "ondertekend" met de privésleutel. De versleutelde hash wordt, samen met het codeondertekeningscertificaat, toegevoegd aan het softwarepakket dat nu klaar is voor verzending of distributie. De reden waarom de hashwaarde wordt ondertekend, en niet de originele software, is dat de hash een kleine hoeveelheid data is (meestal tot 512 bits), die zeer snel kan worden versleuteld, terwijl de originele software erg groot kan zijn en het versleutelen ervan lang kan duren. Bovendien is het niet echt nodig om de softwarecode zelf te versleutelen: het mooie van hashing is dat als de originele softwarecode ook maar met één bit wordt gewijzigd, de hashwaarde die door de hashfunctie wordt geproduceerd totaal anders is.

Best practices voor codeondertekening

Wij adviseren de volgende werkwijzen voor een veilig Code Signing-proces: 

1. Het opslaan van de privésleutels in HSM

   De Hardwarebeveiligingsmodule (HSM) staat de export van cryptografische privésleutels naar software niet toe, omdat deze sleutels daardoor kwetsbaar worden voor aanvallen. Na de vereisten van het CAB Forum van juni 2023 raden we ten zeerste aan om een FIPS 140-2 Niveau 2 (of hoger) gecertificeerde HSM voor codeondertekening.

2. Beperking van toegang tot privésleutels

   We raden ten zeerste aan om slechts minimale verbindingen met clientsystemen met de privésleutels toe te staan. Door de sleuteltoegang te beperken tot een beperkt aantal gebruikers, wordt veel onopvallende gebruikersactiviteit opgelost.

3. Code moet altijd een tijdstempel hebben

   Tijdstempeling is een goede manier om bij te houden wanneer code is ondertekend en helpt bij het controleren van de geldigheidsduur van de handtekening. Het maakt het ook mogelijk om de code te verifiëren nadat het certificaat dat voor de ondertekening is gebruikt, is verlopen of ingetrokken.

4. Vermijd het te vaak gebruiken van één sleutel

   Organisaties gebruiken soms dezelfde sleutel om code te ondertekenen voor meerdere productlijnen en bedrijven. Dit is geen goede aanpak. Als die sleutel gecompromitteerd raakt, lopen alle releases die met die sleutel zijn ondertekend risico. Het is een goede gewoonte om je sleutels zo vaak mogelijk te roteren.

5. Creëer transparantie en centraliseer het beheer

   Organisaties beheren certificaten en sleutels doorgaans handmatig. Maar dit is geen goede aanpak, omdat handmatige processen geen volledig inzicht of gecentraliseerde controle over de sleutels bieden. Het toepassen van verschillende beleidsregels op de sleutels en het reguleren daarvan is lastig zonder een gecentraliseerd beheersysteem.

Wat gebeurt er als de software wordt gedownload?

Aan de ontvangerskant controleert de browser die de software downloadt eerst of het certificaat in de gedownloade code authentiek is en afkomstig is van een betrouwbare CA. Dit is mogelijk omdat de openbare sleutels van de meeste bekende CA's al vooraf zijn geïnstalleerd in de meeste browsers en besturingssystemen.

Als het certificaat niet wordt geverifieerd, waarschuwt de browser u en kan deze, afhankelijk van de beveiligingsinstellingen van de browser, de download al dan niet toestaan. Als de gebruiker deze waarschuwing negeert en probeert de software te installeren, geeft het besturingssysteem een ​​waarschuwing dat de uitgever van de software niet kon worden geverifieerd. Dit ontmoedigt de gebruiker om de software te installeren. Dit komt tegemoet aan het eerste doel van codeondertekening: het vaststellen van code-eigendom.

Als het certificaat is geauthenticeerd, wordt de openbare sleutel uit het certificaat gehaald en gebruikt om de versleutelde hash in het pakket te decoderen. Vervolgens wordt de daadwerkelijk gedownloade software (zonder certificaat en hash) opnieuw gehasht met dezelfde hashfunctie. Deze hashwaarde wordt vergeleken met de ontsleutelde hashwaarde. Als ze overeenkomen, is de software niet gewijzigd. Als een aanvaller de software heeft gewijzigd (bijvoorbeeld door malware toe te voegen), komen de hashes niet overeen. Het besturingssysteem geeft dan een waarschuwing en weigert de software te installeren. Dit dient het tweede doel: het waarborgen van de integriteit van de code.

Codeondertekening voor beveiliging van de softwaretoeleveringsketen

Wanneer een privésleutel wordt gecompromitteerd, verliest het certificaat zijn betrouwbaarheid, waardoor de authenticiteit en integriteit van de software die door dit code-signing certificaat is ondertekend, verloren gaat. Code-signing praktijken zorgen voor veilige productontwikkeling, productie en implementatie. De beste praktijken voor het beschermen van de softwaretoeleveringsketen met veilige code-signing zijn: 

1. Verifieer de code vóór ondertekening en vrijgave

   Organisaties zouden gestroomlijnde codeondertekeningsprocessen moeten gebruiken, zoals CI/CD-pipelines en goedkeuringsprocessen, om te voorkomen dat kwaadaardige code wordt ondertekend. Na ondertekening moet de code of het artefact worden geauthenticeerd en geverifieerd voordat deze aan de gebruikers wordt vrijgegeven. Organisaties zouden ook logs van alle codeondertekeningsprocessen moeten bijhouden voor latere audits.

2. Gecompromitteerde certificaten intrekken

   Om de veiligheid van de code te garanderen, moet intrekking worden gevolgd. Certificaten die zijn gecompromitteerd, moeten door de CA; op deze manier kunnen de beschadigde of gecompromitteerde certificaten niet worden gebruikt voor codeondertekeningsactiviteiten. 

Codeondertekening in cloud-native omgevingen 

Code ondertekening is erg belangrijk bij de implementatie van cloud-native applicaties of DevOps. Voordat we software aan gebruikers distribueren, kunnen we softwaretypen zoals containerimages, applicatie-binaries, enz. ondertekenen en verifiëren. In cloud-native omgevingen is codeondertekening geïntegreerd met CI / CD pipelines om het vertrouwen en de authenticiteit van de software te behouden. Door codeondertekening in cloud-native omgevingen op te nemen, kunnen organisaties het risico voorkomen dat code wordt gemanipuleerd en daardoor schadelijk wordt voor distributie. 

Conclusie

Tegenwoordig is code signing een essentieel onderdeel van de softwareontwikkelingscyclus. Zonder code signing lopen bedrijven het risico gebruikers te verliezen en enorme financiële en reputatierisico's te lopen in geval van malware-aanvallen. Het is daarom cruciaal dat zowel softwarelijnmanagers als senior management inzicht hebben in code signing en het belang ervan voor hun organisaties.