Begrijpen hoe codeondertekening uw organisatie beïnvloedt

Het uitvoerbare bestand dat wordt geleverd, is digitaal ondertekend wanneer een ontwikkelaar zijn programma codeondertekent. Gebruikers van het programma beschouwen de intacte handtekening als bewijs dat de code niet is gewijzigd tussen het moment van verzending en het moment van installatie op het apparaat van de gebruiker. Deze handtekening functioneert als een soort "zegel". Codeondertekening houdt in dat digitale handtekeningen worden toegepast om bestanden te distribueren met behulp van publieke sleutelversleuteling.

De impact van codeondertekening op een organisatie: het bepaalt of uw software zonder beveiligingswaarschuwing kan worden geïnstalleerd, of grote platformen de software überhaupt accepteren voor distributie, en hoe groot de impact is als een ondertekeningssleutel ooit wordt gecompromitteerd, variërend van een enkel onderdeel tot alle productlijnen die dezelfde sleutel delen.

Key Takeaways

• Codeondertekening is niet optioneel voor distributie op de meeste grote platforms; het is een vereiste die de meeste appwinkels en besturingssystemen stellen voordat ze software überhaupt accepteren.
• De daadwerkelijke HSM-basislijn van het CA/Browser Forum voor publiekelijk vertrouwde codeondertekeningscertificaten is FIPS 140-2 Niveau 2 of Common Criteria EAL 4+, van kracht sinds 1 juni 2023. Sommige platforms overtreffen dit minimum met hardware van Niveau 3, maar Niveau 2 is de minimale vereiste, geen ontoereikende kortere weg.
• Voor het volledige aanvalsoppervlak van de softwareleveringsketen waar dit binnen past, zie Codeondertekening 101: uw softwareleveringsketen beveiligen.

Noodzaak van codeondertekening

Tegenwoordig is internet het belangrijkste middel om software te verspreiden, te raadplegen en te gebruiken – bijna elke applicatie op uw computer is waarschijnlijk online gedownload. Het wijdverbreide gebruik van deze media heeft ook het risico op criminele activiteiten vergroot.

Hackers en internetcriminelen kunnen bijvoorbeeld de broncode van het uitvoerbare bestand stelen, er malware aan toevoegen en de software vervolgens online toegankelijk maken voor ontdekking en distributie. Uiteraard infecteert de malware elke gebruiker die dit bestand downloadt en installeert.

Codeondertekening voorkomt dit scenario. Uw besturingssysteem voorkomt dat de installatie van een programma verdergaat zonder eerst te controleren of er een codeondertekeningscertificaat aanwezig is tijdens het downloaden en installeren. De gebruiker wordt op de hoogte gesteld als er op dat moment geen certificaat van een vertrouwde leverancier aanwezig is, waarna hij of zij kan besluiten of de installatie moet worden voortgezet.

Werking van codeondertekening

1. Voor ontwikkelaar

   De maker moet eerst een speciale privésleutel aanmaken die gebruikt kan worden om de gegevens te versleutelen. Volgens de theorie achter publieke sleutelcryptografie is een privé-publiek sleutelpaar een verzameling versleutelingstechnieken die gebruikt kunnen worden voor versleuteling en ontsleuteling. Nadat het sleutelpaar is aangemaakt, wordt de publieke sleutel naar een certificeringsinstantie (CA) gestuurd, een gerenommeerde organisatie die certificaten uitgeeft.

   De CA bevestigt de legitimiteit van de ontwikkelaar voordat deze zijn/haar publieke sleutel aan een digitaal ondertekend certificaat koppelt. Dit is het bewijs van de ontwikkelaar dat hij/zij de rechtmatige eigenaar van de sleutel is. De ontwikkelaar die het certificaat heeft aangevraagd, ontvangt de publieke sleutel en het certificaat terug van de CA.

   

2. Voor Consument:

   Voordat een programma wordt geïnstalleerd, zijn de meeste consumentenbesturingssystemen ingesteld om te controleren op de aanwezigheid van een code-signingcertificaat. Wanneer een installatie wordt aangevraagd, controleert het besturingssysteem eerst de geldigheid van het certificaat voordat het de digest decodeert met een openbare sleutel van de CA.

Wijzigingen aangebracht voor softwareontwikkeling

Een item (document, bestand, script, bibliotheek, enz.) dat tijdens het softwareontwikkelingsproces wordt gebruikt, wordt een tussenliggend artefact genoemd. Deze artefacten moeten gedurende de gehele ontwikkelingscyclus worden ondertekend om te voorkomen dat ze door anderen dan de geautoriseerde maker worden gewijzigd.

Ontwikkelaars kunnen een bestand of script in hun ontwikkelomgeving wijzigen, code ondertekenen en het ondertekende artefact vervolgens in hun repository bewaren voor toekomstig gebruik. De codehandtekening van deze tussenliggende artefacten helpt hackers te voorkomen dat ze ongewenste componenten introduceren tijdens het bouwproces. Er worden veel verschillende componenten gebruikt in hedendaagse softwareontwikkelingsbenaderingen.

Een ernstige inbreuk kan optreden als malware een van deze componenten infiltreert. Het is essentieel dat uw softwareontwikkelingsteams hier rekening mee houden. Uw softwareontwikkelingsteams moeten alle tussenliggende artefacten die ze gebruiken om software te creëren, voorzien van een codehandtekening.

Voordelen van codeondertekening

• Helpt de identiteit van de ontwikkelaar te verifiëren en bevordert zo het vertrouwen aan beide kanten van de transactie.
• Levert bewijs dat er niet met de software is geknoeid en dat deze op de bedoelde manier wordt gebruikt.
• Hierdoor kunnen ontwikkelaars hun werk op meer platforms distribueren, aangezien grote platforms codeondertekening verplicht stellen vóór publicatie.

Best practices voor codeondertekening

1. Voer code-integriteitscontroles uit

   Alle code die ontwikkelaars inchecken, moet digitaal worden ondertekend met hun ondertekeningssleutel. Om ervoor te zorgen dat de uiteindelijke gepubliceerde code ongewijzigd is, moeten alle handtekeningen van ontwikkelaars worden gecontroleerd. De definitieve build moet worden ondertekend en vrijgegeven zodra al deze controles zijn voltooid. Een cruciale stap die ervoor zorgt dat de software-update vrij is van manipulatie en veilig is voor gebruik door uw klanten, is het verifiëren van de integriteit van de broncode.

2. Bewaar sleutels op een zeer veilige locatie

   Een van de grootste fouten die bedrijven maken als het gaat om sleutelbeheer, is het bewaren van de sleutels op een harde schijf, de persoonlijke computer van een ontwikkelaar of op buildservers. Deze fout kan aanvallers een ruime kans geven om uw privésleutels te bemachtigen en verschillende systemen te compromitteren. Bewaar uw codeondertekeningssleutels altijd in zeer veilige cryptografische omgevingen, zoals een Hardware Security Module (HSM). Het CA/Browser Forum vereist sinds 1 juni 2023 HSM- of gelijkwaardige hardwarebeveiliging, minimaal FIPS 140-2 Level 2 of Common Criteria EAL 4+, voor alle publiekelijk vertrouwde codeondertekeningscertificaten; sommige platforms, waaronder CodeSign Secure , gebruiken FIPS 140-2 Level 3-hardware, wat hoger is dan dit minimum. HSM's zijn buitengewoon moeilijk te kraken omdat ze bestand zijn tegen manipulatie. U kunt er zeker van zijn dat er nooit privésleutels worden geëxporteerd en dat niemand anders ooit toegang krijgt tot de codeondertekeningssleutels of deze op oneigenlijke wijze gebruikt.

3. Draai toetsen

   Soms gebruiken organisaties dezelfde sleutel om releases voor verschillende productlijnen en bedrijven te ondertekenen. Dit is absoluut geen goed idee. Alle releases die u met de codeondertekeningssleutel hebt ondertekend, lopen het risico gehackt te worden. In plaats daarvan is het verstandig om uw sleutels regelmatig te wisselen. Gebruik daarnaast aparte en onafhankelijke sleutels om verschillende releases binnen DevOps-teams te ondertekenen.

Veelgestelde Vragen / FAQ

Is FIPS 140-2 niveau 3 vereist voor het codeondertekenen van HSM's?

Nee. De minimale vereisten van het CA/Browser Forum voor publiekelijk vertrouwde codeondertekeningscertificaten zijn FIPS 140-2 niveau 2 of Common Criteria EAL 4+. Niveau 3 overtreft dat minimum; sommige platforms hanteren het als een strengere interne standaard, maar het is niet de vereiste voor naleving.

Wat zijn de werkelijke organisatorische kosten van het overslaan van codeondertekening?

Naast de beveiligingswaarschuwingen die gebruikers zien, weigeren de meeste grote platforms (appwinkels, browsers, updateprocessen van besturingssystemen) software zonder ondertekening ronduit. Hierdoor is codeondertekening een vereiste voor distributie, en niet slechts een teken van vertrouwen.

Moet hetzelfde sleutelsymbool worden gebruikt bij de release van meerdere productlijnen?

Nee. Het delen van één sleutel over meerdere productlijnen betekent dat één inbreuk elke release die met die sleutel is ondertekend, in gevaar brengt. Gebruik aparte sleutels per productlijn of team om de impact van een inbreuk te beperken.

Conclusie

Een codeondertekeningscertificaat is essentieel voor het vertrouwen van de gebruiker en om te garanderen dat uw broncode intact is. Bovendien zorgt het ervoor dat uw applicatie niet kwetsbaar is voor cyberaanvallen. De toenemende cyberaanvallen en de enorme app-markt betekenen dat u op het gebied van beveiliging goed voorbereid moet zijn.