Revisjon og valg av kryptografiske avhengigheter

Det kryptografiske biblioteket De velger, er en av de mest avgjørende sikkerhetsbeslutningene i et prosjekt. Selv velmenende utviklere kan lage usikre systemer dersom de bruker et dårlig bibliotek. Et veldesignet bibliotek gjør det derimot vanskelig å begå katastrofale feil. Utvelgelsesprosessen bør være systematisk og vurdere sikkerhetshistorikk, API-design, vedlikeholdsstatus og egnethet for formålet.

Et av de første spørsmålene om et kryptografisk bibliotek er når det sist ble revidert uavhengig, og hva revisjonen omfattet. En revisjon fra for fem år siden av versjon 1.0 gir mindre trygghet for versjon 3.0 som brukes i dag. Se etter revisjoner utført av anerkjente sikkerhetsselskaper (NCC Group, Trail of Bits, Quarkslab, Cure53) som dekker den spesifikke funksjonaliteten De planlegger å bruke. Noen biblioteker publiserer revisjonsrapporter offentlig; fravær av enhver revisjon er en betydelig risikofaktor.

Gå gjennom bibliotekets CVE-historikk i NVD (National Vulnerability Database). Se på hvor mange CVE-er som finnes, alvorlighetsgradene deres, hvilke typer sårbarheter de representerer (logiske feil, minnekorrupsjon eller svakheter i algoritmer), og hvor raskt vedlikeholderne publiserte oppdateringer. Et bibliotek med sporadiske CVE-er som raskt blir rettet, viser responsivt vedlikehold. Et bibliotek med mange CVE-er med høy alvorlighetsgrad eller treg oppdatering er et tydelig varselsignal.

Uvedlikeholdte kryptografiske biblioteker er farlige. Kontroller datoen for siste commit, utgivelsesfrekvensen og om sikkerhetsadvarsler blir håndtert. Et bibliotek med siste commit for tre år siden kan ha kjente sårbarheter som aldri blir rettet. Størrelsen på fellesskapet har betydning for bredden i gjennomgangen: Biblioteker som brukes mye, får mer oppmerksomhet fra sikkerhetsforskere enn nisjeprosjekter.

Et mindre og mer førende API-omfang er bedre for sikkerheten. Biblioteker som eksponerer mange algoritmevalg og konfigurasjonsmuligheter, skaper flere muligheter for feilkonfigurering. Sammenlign libsodium (én funksjon per bruksområde, fast algoritme) med OpenSSL EVP (velg chiffer, modus, nøkkelstørrelse, utfylling og IV-håndtering separat). Jo vanskeligere det er å bruke et bibliotek feil, desto bedre egner det seg for sikkerhetsbevisste prosjekter.

For operasjoner som involverer hemmelige data (nøkkelsammenligning, dekryptering og signaturverifisering) må implementasjonen bruke algoritmer som tar konstant tid, og som ikke forgrener seg eller aksesserer minne basert på hemmelige verdier. Kontroller at bibliotekdokumentasjonen uttrykkelig angir garantier for konstant tid ved sensitive operasjoner, eller at kildekoden bruker godkjente funksjoner for sammenligning i konstant tid. Biblioteker uten denne garantien er sårbare for tidsbaserte sidekanalangrep.

Et godt kryptografisk bibliotek bør støtte moderne algoritmer og planlegge å fase ut foreldede algoritmer. Det bør tilby ChaCha20-Poly1305 eller AES-256-GCM for kryptering, Ed25519 eller ECDSA P-256 for signaturer, X25519 for nøkkelutveksling og Argon2id for hashing av passord. Biblioteker som bare tilbyr eldre algoritmer (DES, RC4, MD5 og SHA-1), egner seg ikke for nye utrullinger, uavhengig av de øvrige egenskapene.

Vurder transitive avhengigheter: Hvilke biblioteker er det kryptografiske biblioteket avhengig av, og hvordan er sikkerhetsnivået deres? Et bibliotek uten eksterne avhengigheter (som libsodium) har minimal risiko i leverandørkjeden. Et bibliotek som er avhengig av et dusin npm-pakker, som hver har sine egne avhengigheter, har en stor angrepsflate i leverandørkjeden. Kontroller om biblioteket bruker reproduserbare bygg, slik at det kan verifiseres at den distribuerte binærfilen samsvarer med kildekoden.

Regulerte bransjer (helsevesen, finans og offentlig sektor) krever ofte kryptografiske moduler som er validert i henhold til FIPS 140-2 eller 140-3. FIPS-validering er dyrt og tidkrevende, så bare et begrenset utvalg biblioteker har dette. OpenSSL med sin FIPS-provider, BoringCrypto (som brukes i Gos crypto/tls) og enkelte HSM-biblioteker er FIPS-validerte. Hvis utrullingen krever FIPS-samsvar, begrenser dette kravet utvalget av biblioteker betydelig.

Maskinvarebaserte sikkerhetsmoduler (HSM-er) og skybaserte KMS-tjenester har ofte proprietære API-er for nøkkeloperasjoner. Hvis applikasjonen kobles tett til AWS KMS eller en bestemt HSM-leverandør, oppstår det risiko for leverandørbinding. Vurder om biblioteket tilbyr abstraksjonslag (som Tinks KMS-integrasjon) som gjør det mulig å bytte leverandør. Ta også i betraktning at migreringskostnadene kan bli betydelige dersom HSM-leverandøren avslutter støtten eller øker prisene.

Den viktigste regelen ved valg av kryptografiske avhengigheter er å bruke velkjente biblioteker som er bredt tatt i bruk og implementerer etablerte standarder, og aldri implementere kryptografiske primitiver selv. Uansett hvor godt De forstår teorien, er det svært vanskelig å implementere AES, RSA, elliptisk kurve-operasjoner eller autentisert kryptering korrekt i produksjonskode. Det er nesten aldri verdt risikoen sammenlignet med å bruke et utprøvd bibliotek.

Sjekkliste for valg av bibliotek: Kontroller omfanget av og rapporten fra en nylig, uavhengig revisjon, gå gjennom CVE-historikk og responstid for sikkerhetsoppdateringer, bekreft aktivt vedlikehold og engasjement i fellesskapet, foretrekk mindre API-omfang som motstår feilbruk, bekreft garantier for konstant tid ved sensitive operasjoner, sørg for støtte for moderne algoritmer, vurder avhengigheter i leverandørkjeden, kontroller FIPS-validering dersom bransjen er regulert, vurder risikoen for leverandørbinding til KMS, og bruk alltid etablerte biblioteker i stedet for å implementere primitiver.