Cryptografische dependencies auditen en selecteren

De cryptografische bibliotheek die je kiest, is een van de belangrijkste beveiligingsbeslissingen in een project. Zelfs goedbedoelende ontwikkelaars kunnen met een slechte bibliotheek onveilige systemen produceren. Omgekeerd maakt een goed ontworpen bibliotheek het moeilijk om rampzalige fouten te maken. Het keuzeproces moet systematisch zijn en de beveiligingsgeschiedenis, het API-ontwerp, de onderhoudsstatus en de geschiktheid voor het doel beoordelen.

Een van de eerste vragen over een cryptografische bibliotheek is wanneer deze voor het laatst onafhankelijk is geaudit en wat die audit omvatte. Een audit van vijf jaar geleden op versie 1.0 biedt minder zekerheid voor versie 3.0 die nu wordt gebruikt. Zoek naar audits die zijn uitgevoerd door gerenommeerde beveiligingsbedrijven, zoals NCC Group, Trail of Bits, Quarkslab en Cure53, en die de specifieke functionaliteit behandelen die je wilt gebruiken. Sommige bibliotheken publiceren auditrapporten openbaar; het ontbreken van een audit is een belangrijke risicofactor.

Bekijk de CVE-geschiedenis van de bibliotheek in de NVD (National Vulnerability Database). Let op het aantal CVE's, de ernstclassificaties, de categorieën kwetsbaarheden die ze vertegenwoordigen, zoals logische fouten, geheugenbeschadiging of zwakke plekken in algoritmen, en hoe snel de beheerders beveiligingsupdates uitbrengen. Een bibliotheek met af en toe een CVE die snel wordt verholpen, laat zien dat het onderhoud responsief is. Veel CVE's met een hoge ernst of trage beveiligingsupdates zijn een rode vlag.

Niet-onderhouden cryptografische bibliotheken zijn gevaarlijk. Controleer de datum van de laatste commit, de uitgavefrequentie en of beveiligingsadviezen worden opgevolgd. Een bibliotheek waarvan de laatste commit drie jaar geleden is gedaan, kan bekende kwetsbaarheden bevatten die nooit worden verholpen. De omvang van de gemeenschap is belangrijk voor de breedte van de beoordeling: veelgebruikte bibliotheken worden grondiger onderzocht door beveiligingsonderzoekers dan specialistische projecten.

Een kleiner, meer uitgesproken API-oppervlak is beter voor de beveiliging. Bibliotheken die veel algoritmeopties en configuratieopties blootstellen, creëren mogelijkheden voor verkeerde configuratie. Vergelijk libsodium, met één functie per gebruikssituatie en een vast algoritme, met OpenSSL EVP, waarbij je het cijfer, de modus, de sleutellengte, de opvulling en de IV-verwerking afzonderlijk kiest. Hoe moeilijker het is om een bibliotheek verkeerd te gebruiken, hoe geschikter deze is voor beveiligingsbewuste projecten.

Voor bewerkingen met geheime gegevens, zoals sleutelvergelijking, ontsleuteling en handtekeningverificatie, moet de implementatie algoritmen in constante tijd gebruiken die geen vertakkingen uitvoeren of geheugen benaderen op basis van geheime waarden. Controleer of de documentatie van de bibliotheek uitdrukkelijk garanties voor constante tijd geeft voor gevoelige bewerkingen, of dat de broncode goedgekeurde functies voor vergelijkingen in constante tijd gebruikt. Bibliotheken zonder deze garantie zijn kwetsbaar voor timingaanvallen via zijkanalen.

Een goede cryptografische bibliotheek moet moderne algoritmen ondersteunen en van plan zijn verouderde algoritmen uit te faseren. De bibliotheek moet ChaCha20-Poly1305 of AES-256-GCM bieden voor versleuteling, Ed25519 of ECDSA P-256 voor handtekeningen, X25519 voor sleuteluitwisseling en Argon2id voor het hashen van wachtwoorden. Bibliotheken die alleen verouderde algoritmen bieden, zoals DES, RC4, MD5 en SHA-1, zijn niet geschikt voor nieuwe implementaties, ongeacht hun andere kwaliteiten.

Beoordeel transitieve afhankelijkheden: van welke bibliotheken is je cryptografische bibliotheek afhankelijk en hoe staat het met hun beveiliging? Een bibliotheek zonder externe afhankelijkheden, zoals libsodium, brengt minimaal risico voor de toeleveringsketen met zich mee. Een bibliotheek die afhankelijk is van een dozijn npm-pakketten, elk met hun eigen afhankelijkheden, heeft via de toeleveringsketen een groot aanvalsoppervlak. Controleer of de bibliotheek reproduceerbare builds gebruikt, zodat je kunt verifiëren dat het verspreide binaire bestand overeenkomt met de broncode.

Gereguleerde sectoren, zoals de gezondheidszorg, financiële dienstverlening en overheid, vereisen vaak cryptografische modules die volgens FIPS 140-2 of 140-3 zijn gevalideerd. FIPS-validatie is duur en tijdrovend, waardoor slechts een deel van de bibliotheken hierover beschikt. OpenSSL met zijn FIPS-provider, BoringCrypto, dat wordt gebruikt in Go's crypto/tls, en sommige HSM-bibliotheken zijn volgens FIPS gevalideerd. Als je implementatie FIPS-conformiteit vereist, beperkt deze vereiste je keuze aan bibliotheken aanzienlijk.

Hardware Security Modules (HSM's) en cloud-KMS-diensten hebben vaak bedrijfseigen API's voor sleutelbewerkingen. Als je je toepassing nauw koppelt aan AWS KMS of een specifieke HSM-leverancier, ontstaat het risico op leveranciersafhankelijkheid. Beoordeel of de bibliotheek abstractielagen biedt, zoals de KMS-integratie van Tink, waarmee je van provider kunt wisselen. Houd er ook rekening mee dat migratiekosten aanzienlijk kunnen zijn als de HSM-leverancier stopt met ondersteuning of de prijzen verhoogt.

De belangrijkste regel bij het kiezen van cryptografische afhankelijkheden: gebruik bekende, breed toegepaste bibliotheken die gevestigde standaarden implementeren en implementeer nooit zelf cryptografische primitieven. Hoe goed je de theorie ook begrijpt, AES, RSA, bewerkingen met elliptische krommen of geauthenticeerde versleuteling correct implementeren in productiecode is buitengewoon moeilijk. Vergeleken met het gebruik van een bewezen bibliotheek is het risico vrijwel nooit de moeite waard.

Checklist voor het kiezen van een bibliotheek: controleer de reikwijdte en het rapport van een recente onafhankelijke audit, bekijk de CVE-geschiedenis en de reactietijd op beveiligingsupdates, controleer actief onderhoud en betrokkenheid van de gemeenschap, geef de voorkeur aan kleinere API-oppervlakken die verkeerd gebruik tegengaan, bevestig garanties voor constante tijd bij gevoelige bewerkingen, zorg voor ondersteuning van moderne algoritmen, beoordeel afhankelijkheden in de toeleveringsketen, controleer FIPS-validatie als je in een gereguleerde sector werkt, houd rekening met het risico op leveranciersafhankelijkheid bij KMS en gebruik altijd gevestigde bibliotheken in plaats van zelf cryptografische primitieven te implementeren.