OpenSSL API: Kernestrukturer og faldgruber

EVP (Envelope)-API'en er OpenSSL's grænseflade på højt niveau til kryptografiske operationer og er den korrekte API at bruge i applikationskode. Den abstraherer algoritmespecifikke detaljer bag en ensartet grænseflade, understøtter automatisk hardwareacceleration via engine- og provider-mekanismer og håndterer detaljer om polstring og tilstand korrekt. OpenSSL's lavniveau-API'er, der er specifikke for algoritmer, er forældede i moderne versioner og bør undgås.

Symmetrisk kryptering i OpenSSL bruger kontekstobjektet EVP_CIPHER_CTX. Rækkefølgen af operationerne er: EVP_CIPHER_CTX_new for at allokere konteksten, EVP_EncryptInit_ex for at initialisere den med krypteringsalgoritme og nøgle, EVP_EncryptUpdate gentagne gange for at behandle data, EVP_EncryptFinal_ex for at tømme den sidste blok og hente det resterende resultat samt EVP_CIPHER_CTX_free for at frigive hukommelsen. Det er en almindelig fejl at springe EncryptFinal_ex over, fordi det giver et afkortet resultat.

Beskedfordøjelse bruger EVP_MD_CTX på tilsvarende måde: EVP_MD_CTX_new, EVP_DigestInit_ex med algoritmen (EVP_sha256(), EVP_sha3_256() osv.), EVP_DigestUpdate med datablokke og EVP_DigestFinal_ex for at hente hashværdien. HMAC-operationer bruger en separat HMAC_CTX eller den nyere EVP_MAC-API. EVP-abstraktionen gør det muligt at udskifte hash-algoritmer ved kun at ændre ét funktionskald.

EVP_PKEY er det samlede asymmetriske nøgleobjekt i OpenSSL og understøtter RSA, ECDSA, Ed25519, DH og andre algoritmer via en enkelt grænseflade. Nøgler oprettes fra PEM- eller DER-filer med PEM_read_PrivateKey og PEM_read_PUBKEY eller genereres med EVP_PKEY_keygen. EVP_PKEY_sign og EVP_PKEY_verify udfører signering og verificering for enhver nøgletype ved hjælp af de samme funktionskald.

BIO (Basic I/O) er OpenSSL's abstraktionslag til indlæsning og skrivning, som gør det muligt at læse og skrive TLS-beskyttede eller rå data gennem en kæde af BIO-objekter. En BIO-kæde kan for eksempel bestå af BIO_new_ssl (TLS-lag), der er kædet sammen med BIO_new_connect (TCP-forbindelse). Når du skriver til SSL-BIO'en, krypteres og sendes data automatisk; læsning dekrypterer modtagne data. BIO-objekter understøtter filer, sockets, hukommelsesbuffere og filtre (base64, buffering).

TLS-forbindelser i OpenSSL bruger to objekter: SSL_CTX (kontekst), som gemmer den fælles konfiguration: certifikat, privat nøgle, CA-pakke, begrænsninger for protokolversioner og krypteringsliste. SSL repræsenterer en individuel forbindelse, der er afledt af konteksten. Opret én SSL_CTX pr. applikation, og opret derefter SSL-objekter ud fra den til hver forbindelse. SSL_read og SSL_write overfører klartekst; OpenSSL håndterer al TLS-indramning og kryptering internt.

Den farligste OpenSSL-fejl er at ignorere returværdier. EVP_EncryptFinal_ex, SSL_read og SSL_write returnerer negative værdier eller nul for at angive fejl. Hvis du kalder SSL_read i en løkke uden at kontrollere SSL_get_error, kan det medføre uendelige løkker eller skjulte fejl. Returværdien skal kontrolleres for alle OpenSSL-funktioner, der kan mislykkes; fejlene angiver ofte sikkerhedsrelevante forhold som fejl under håndtrykket eller fejl ved certifikatvalidering.

SSL_read og SSL_write kan returnere SSL_ERROR_WANT_READ eller SSL_ERROR_WANT_WRITE, hvilket angiver, at operationen skal prøves igen efter at have ventet på indlæsning eller skrivning. Det er ikke egentlige fejl, men meddelelser om ikke-blokerende indlæsning og skrivning. Kode, der ikke kalder SSL_get_error og forgrener korrekt på want-read/want-write, vil enten køre i en travl løkke eller fejlagtigt behandle disse forhold som fejl. Brug altid SSL_get_error til at fortolke negative returværdier fra TLS-indlæsnings- og -skrivningsoperationer.

OpenSSL indeholder mange forældede lavniveau-funktioner, som ikke bør forekomme i ny kode: direkte kald til DES_encrypt1, direkte brug af SHA1- eller MD5-hashfunktioner uden EVP-laget, RSA_private_encrypt i stedet for EVP_PKEY_sign samt AES_encrypt (AES-ECB uden autentificering). Disse API'er omgår sikkerhedstjek, bruger forældede algoritmer eller er ganske enkelt mindre sikre end deres EVP-ækvivalenter. Compileradvarsler markerer ofte brug af forældede API'er.

OpenSSL bruger eksplicit hukommelseshåndtering; alle allokerede objekter skal frigives eksplicit. Almindelige hukommelseslækager omfatter at glemme EVP_CIPHER_CTX_free efter kryptering, ikke at kalde SSL_free efter lukning af en forbindelse eller ikke at kalde X509_free efter certifikatverificering. I langkørende servere medfører disse lækager gradvis udtømning af hukommelsen. Brug værktøjer som valgrind eller AddressSanitizer til at finde hukommelseslækager i OpenSSL under udviklingen.

OpenSSL 3.0 introducerede providermodellen, som erstatter den ældre ENGINE-API til hardwareacceleration. Providere er moduler, der kan indlæses, og som implementerer kryptografiske algoritmer: standardprovideren (software), legacy-provideren (ældre algoritmer), FIPS-provideren (valideret efter FIPS 140-2) samt tredjepartsprovidere til HSM'er. FIPS-provideren muliggør drift i overensstemmelse med kravene ved at begrænse de tilgængelige algoritmer til dem, der er godkendt efter FIPS 140-2, uden at applikationskoden skal ændres.

Opsummering af OpenSSL-API'en: Brug altid EVP-API'en på højt niveau, EVP_CIPHER_CTX til symmetriske operationer, EVP_MD_CTX til hashberegning, EVP_PKEY til asymmetriske nøgler, BIO-kæder til abstraktion af indlæsning og skrivning, SSL_CTX og SSL til TLS-forbindelser, kontrollér altid returværdier, og kald SSL_get_error, frigiv alle allokerede objekter for at forhindre lækager, undgå forældede lavniveau-funktioner, og brug OpenSSL 3.0-providere til overensstemmelse med FIPS-krav eller hardwareacceleration.