API de OpenSSL: estructuras principales y errores comunes

La API EVP (Envelope) es la interfaz de alto nivel de OpenSSL para operaciones criptográficas y es la API adecuada para utilizar en el código de las aplicaciones. Abstrae los detalles específicos de cada algoritmo mediante una interfaz uniforme, admite automáticamente la aceleración de hardware mediante engines y providers, y gestiona correctamente los detalles del padding y del modo. Las API de bajo nivel específicas de cada algoritmo de OpenSSL están obsoletas en las versiones modernas y deben evitarse.

El cifrado simétrico en OpenSSL utiliza el objeto de contexto EVP_CIPHER_CTX. La secuencia de operaciones es: EVP_CIPHER_CTX_new para asignar el contexto, EVP_EncryptInit_ex para inicializarlo con el cifrador y la clave, EVP_EncryptUpdate repetidamente para procesar los datos, EVP_EncryptFinal_ex para procesar el bloque final y obtener la salida restante, y EVP_CIPHER_CTX_free para liberar la memoria. Omitir EncryptFinal_ex es un error frecuente que produce una salida truncada.

El cálculo de resúmenes de mensaje utiliza EVP_MD_CTX de forma similar: EVP_MD_CTX_new, EVP_DigestInit_ex con el algoritmo (EVP_sha256(), EVP_sha3_256(), etc.), EVP_DigestUpdate con bloques de datos y EVP_DigestFinal_ex para obtener el hash. Las operaciones HMAC utilizan un HMAC_CTX independiente o la API EVP_MAC más reciente. La abstracción EVP permite cambiar de algoritmo de hash modificando una sola llamada a función.

EVP_PKEY es el objeto unificado de claves asimétricas de OpenSSL, compatible con RSA, ECDSA, Ed25519, DH y otros algoritmos mediante una única interfaz. Las claves se crean a partir de archivos PEM o DER con PEM_read_PrivateKey y PEM_read_PUBKEY, o se generan con EVP_PKEY_keygen. EVP_PKEY_sign y EVP_PKEY_verify realizan la firma y la verificación para cualquier tipo de clave mediante las mismas llamadas a función.

BIO (Basic I/O) es la capa de abstracción de E/S de OpenSSL, que permite leer y escribir datos protegidos por TLS o datos sin procesar mediante una cadena de objetos BIO. Una cadena BIO podría ser BIO_new_ssl (capa TLS) encadenado con BIO_new_connect (conexión TCP). Escribir en el BIO SSL cifra y envía los datos automáticamente; leerlos descifra los datos recibidos. Los objetos BIO admiten archivos, sockets, búferes de memoria y filtros (base64, buffering).

Las conexiones TLS en OpenSSL utilizan dos objetos: SSL_CTX (contexto) almacena la configuración compartida: certificado, clave privada, paquete de CA, límites de versión del protocolo y lista de cifradores. SSL representa una conexión individual derivada del contexto. Cree un SSL_CTX por aplicación y, después, cree objetos SSL a partir de él para cada conexión. SSL_read y SSL_write transfieren texto sin formato; OpenSSL gestiona internamente todo el encuadre y el cifrado TLS.

El error más peligroso al utilizar OpenSSL es ignorar los valores de retorno. EVP_EncryptFinal_ex, SSL_read y SSL_write devuelven valores negativos o cero para indicar errores. Llamar a SSL_read en un bucle sin comprobar SSL_get_error puede provocar bucles infinitos o hacer que se pasen por alto errores. Debe comprobarse el valor de retorno de toda función de OpenSSL que pueda fallar; los fallos suelen indicar condiciones relevantes para la seguridad, como errores durante el handshake o errores de validación de certificados.

SSL_read y SSL_write pueden devolver SSL_ERROR_WANT_READ o SSL_ERROR_WANT_WRITE, lo que indica que la operación debe reintentarse después de esperar a la E/S. No son errores reales, sino notificaciones de E/S no bloqueante. El código que no llama a SSL_get_error ni toma correctamente una decisión según want-read o want-write entrará en un bucle activo o tratará incorrectamente estas condiciones como errores. Utilice siempre SSL_get_error para interpretar los valores de retorno negativos de las operaciones de E/S de TLS.

OpenSSL contiene muchas funciones de bajo nivel obsoletas que no deberían aparecer en código nuevo: llamadas directas a DES_encrypt1, uso directo de las funciones de hash SHA1 o MD5 sin la capa EVP, RSA_private_encrypt en lugar de EVP_PKEY_sign y AES_encrypt (AES ECB sin autenticación). Estas API omiten comprobaciones de seguridad, utilizan algoritmos obsoletos o son sencillamente menos seguras que sus equivalentes EVP. Las advertencias del compilador suelen señalar el uso de API obsoletas.

OpenSSL utiliza gestión explícita de memoria; cada objeto asignado debe liberarse explícitamente. Algunas fugas de memoria habituales son olvidar EVP_CIPHER_CTX_free después del cifrado, no llamar a SSL_free después de cerrar una conexión o no llamar a X509_free después de verificar un certificado. En servidores de larga duración, estas fugas provocan un agotamiento gradual de la memoria. Utilice herramientas como valgrind o AddressSanitizer para detectar fugas de memoria de OpenSSL durante el desarrollo.

OpenSSL 3.0 introdujo el modelo de providers, que sustituye a la antigua API ENGINE para la aceleración de hardware. Los providers son módulos cargables que implementan algoritmos criptográficos: el provider predeterminado (software), el provider legacy (algoritmos antiguos), el provider FIPS (validado según FIPS 140-2) y providers de terceros para HSM. El provider FIPS permite operar de forma conforme al restringir los algoritmos disponibles a los aprobados por FIPS 140-2, sin cambiar el código de la aplicación.

¿Por qué se prefiere la API EVP de OpenSSL a las API de bajo nivel específicas de cada algoritmo?

Resumen de la API de OpenSSL: utilice siempre la API EVP de alto nivel; EVP_CIPHER_CTX para operaciones simétricas; EVP_MD_CTX para hashing; EVP_PKEY para claves asimétricas; cadenas BIO para la abstracción de E/S; SSL_CTX y SSL para conexiones TLS; compruebe siempre los valores de retorno y llame a SSL_get_error; libere todos los objetos asignados para evitar fugas; evite las funciones de bajo nivel obsoletas; y utilice los providers de OpenSSL 3.0 para cumplir con FIPS o disponer de aceleración de hardware.