SoftHSM: instalación y uso en Ubuntu

Introducción

Los tokens hardware o Hardware Security Modules (HSM) se usan en distintas aplicaciones para almacenar claves criptográficas (públicas y privadas) y certificados. Ejemplos de HSM hardware son NitroKey y Smartcard-HSM. También existen alternativas software como SoftHSM (v2), desarrollado dentro del proyecto OpenDNSSEC.

SoftHSM es, en esencia, una implementación de un almacén criptográfico accesible a través de la interfaz PKCS#11. PKCS#11 es un estándar usado para comunicar o acceder a dispositivos criptográficos como HSMs y tarjetas inteligentes. El propósito principal de los HSM es generar claves criptográficas y firmar/encriptar información sin exponer la clave privada.

Contexto breve: OpenDNSSEC necesitaba una opción que permitiera a sus usuarios trabajar sin comprar hardware físico. Para eso surgió SoftHSM, una implementación software genérica compatible con PKCS#11 y pensada para integrarse con OpenDNSSEC y otros productos criptográficos.

Variantes de intención y términos relacionados

• Instalar SoftHSM en Ubuntu
• Configurar SoftHSM con PKCS#11
• Uso de SoftHSM vs HSM hardware
• Integración SoftHSM y OpenSC

Dependencias

Puedes compilar SoftHSM usando las bibliotecas criptográficas Botan u OpenSSL. Si usas Botan, asegúrate de compilar con soporte para GNU MP (–with-gnump) para mejorar el rendimiento en operaciones con clave pública.

Importante: instala también las cabeceras de desarrollo (por ejemplo openssl-dev o libssl-dev según la distribución) antes de ejecutar ./configure.

Instalación desde fuentes

SoftHSM está disponible en el sitio de OpenDNSSEC y puede descargarse con wget:

wget https://dist.opendnssec.org/source/softhsm-2.3.0.tar.gz

Extrae el paquete:

tar xzf softhsm-2.3.0.tar.gz

Después de la extracción, ejecuta el script configure para comprobar dependencias:

./configure

Si falta alguna cabecera, configure mostrará errores. Por ejemplo, al faltar las cabeceras de OpenSSL verás un mensaje similar a este:

Soluciona la dependencia instalando el paquete de desarrollo apropiado. En algunas distribuciones el paquete se llama openssl-dev; en Ubuntu suele ser libssl-dev:

apt-get install libssl-dev

Vuelve a ejecutar ./configure; si todo está correcto verás que las dependencias están satisfechas:

Opciones de configure

El script configure ofrece varias opciones para elegir backend criptográfico, soporte de ECC/GOST, integración con p11-kit y almacenamiento de objetos. Puedes verlas con:

./configure --help

--disable-ecc       Disable support for ECC (default enabled)
--disable-gost      Disable support for GOST (default enabled)
--disable-visibility    Disable hidden visibilty link mode [enabled]
--with-crypto-backend   Select crypto backend (openssl|botan)
--with-openssl=PATH Specify prefix of path of OpenSSL
--with-botan=PATH   Specify prefix of path of Botan
--with-migrate      Build the migration tool. Used when migrating
        a SoftHSM v1 token database. Requires SQLite3
--with-objectstore-backend-db
            Build with database object store (SQLite3)
--with-sqlite3=PATH Specify prefix of path of SQLite3
--disable-p11-kit   Disable p11-kit integration (default enabled)
--with-p11-kit=PATH Specify install path of the p11-kit module, will
            override path given by pkg-config

Selecciona las opciones según tus requisitos. Por ejemplo, para usar OpenSSL como backend y habilitar la migración desde v1 podrías usar:

./configure --with-crypto-backend=openssl --with-migrate

Compila el código fuente:

make

Instala los binarios y bibliotecas:

make install

Nota: make install puede requerir privilegios de administrador (sudo) según el prefijo de instalación.

Archivo de configuración

La ubicación por defecto del archivo de configuración es /etc/softhsm2.conf. Puedes cambiarla exportando la variable de entorno SOFTHSM2_CONF antes de ejecutar herramientas de SoftHSM:

export SOFTHSM2_CONF=Path_of_SoftHSM_Conf_file

El archivo de configuración define la ubicación física del almacén (token database), opciones de backend y parámetros del objeto.

Inicializar un token SoftHSM

Antes de usar SoftHSM debes inicializar un token. Puedes usar la utilidad softhsm2-util o interactuar por PKCS#11.

Inicializa un token en la ranura 0 y asígnale una etiqueta:

softhsm2-util --init-token --slot 0 --label "Token-1"

Durante la inicialización se te pedirá establecer un PIN de Security Officer (SO) y un PIN de usuario. El SO PIN sirve para tareas de administración como re-inicializar el token. El PIN de usuario lo usará la aplicación que necesite acceder al token (por ejemplo, Mozilla Firefox).

Nota: una vez inicializado un token, SoftHSM añade automáticamente nuevos slots para tokens no inicializados. Los tokens inicializados pueden reasignarse a otra ranura según su número de serie. Para buscar un token es más seguro usar la etiqueta o el número de serie en la lista de slots.

Otras opciones útiles de softhsm2-util incluyen listado de objetos, exportación e importación de claves según el soporte del backend.

Lista de slots y tokens:

Respaldo

Todos los tokens y sus objetos se almacenan en la ubicación indicada por softhsm2.conf. Por tanto el respaldo puede realizarse mediante copia de archivos del directorio configurado. Asegura permisos adecuados y confidencialidad del respaldo: los archivos contienen objetos en formato que deben tratarse como secretos.

Importante: cifra y controla el acceso a las copias de respaldo y almacénalas fuera del servidor de producción cuando sea posible.

SoftHSM con utilidades OpenSC

Para acceder a SoftHSM con utilidades PKCS#11 puedes usar OpenSC. En Debian/Ubuntu:

apt-get install opensc

Ejemplo de test con pkcs11-tool (el parámetro -t prueba el mecanismo):

pkcs11-tool --module /usr/local/lib/softhsm/libsofthsm2.so -l -t

Buenas prácticas y seguridad

• Control de acceso: limita quién puede leer el archivo de configuración y el directorio de tokens. Usa permisos mínimos (por ejemplo 600 para archivos sensibles).
• Backup seguro: cifra las copias de respaldo y registra su localización. No almacenes backups en el mismo host sin cifrado.
• Rotación de PIN/clave: define políticas de rotación y revocación para PINs y claves internas.
• Entorno de producción: considera usar un HSM hardware para cargas críticas o cumplimiento de normativas. SoftHSM es útil para pruebas, desarrollo y entornos con requisitos moderados.
• Monitorización: registra accesos y fallos de autenticación. Integra con sistemas de auditoría si es necesario.

Cuándo no usar SoftHSM

• No utilices SoftHSM como sustituto de un HSM hardware en entornos donde la seguridad física y el cumplimiento regulatorio exigen módulos certificados (por ejemplo, FIPS 140-2/3, Common Criteria).
• Evita SoftHSM para claves maestras que protejan datos altamente sensibles en producción si no controlas adecuadamente la infraestructura.

Alternativas y migración

• HSM hardware: NitroKey, Thales, YubiHSM, Gemalto. Ideales para entornos de alta seguridad.
• Otras soluciones software: dependientes del caso de uso; comparar compatibilidad PKCS#11 y soporte del proveedor.
• Migración desde SoftHSM v1: SoftHSM incluye una herramienta de migración que requiere SQLite3. Compila con –with-migrate si necesitas migrar bases de tokens.

Modelo mental rápido

Piensa en SoftHSM como una “caja fuerte digital” accesible mediante una interfaz estándar (PKCS#11). Las aplicaciones piden a la caja realizar operaciones (firmar, cifrar) sin obtener la clave privada.

Lista de verificación por rol

Administrador:

• Verificar dependencias y compilar con el backend deseado.
• Configurar permisos y backups cifrados.
• Documentar el proceso de recuperación.

DevOps:

• Automizar la instalación y el despliegue del archivo de configuración.
• Añadir pruebas de integración que validen operaciones PKCS#11.

Responsable de seguridad:

• Revisar políticas de PIN y almacenamiento de backups.
• Auditar accesos y configurar alertas.

Procedimiento (SOP) rápido para instalar y preparar SoftHSM

1. Instala dependencias (libssl-dev, sqlite3 si usas DB, build-essential).
2. Descargar paquete: wget https://dist.opendnssec.org/source/softhsm-2.3.0.tar.gz
3. Extraer: tar xzf softhsm-2.3.0.tar.gz
4. Configurar: ./configure –with-crypto-backend=openssl –with-migrate (opcional)
5. Compilar: make
6. Instalar: sudo make install
7. Configurar /etc/softhsm2.conf y establecer SOFTHSM2_CONF si hace falta.
8. Inicializar token: softhsm2-util –init-token –slot 0 –label “Token-1”
9. Probar con pkcs11-tool o la aplicación destino.

Pruebas y criterios de aceptación

• La biblioteca PKCS#11 se carga correctamente desde la ruta de instalación.
• softhsm2-util enumera al menos un slot y permite inicializar un token.
• Las operaciones de firma/prueba con pkcs11-tool devuelven éxito con -t.
• Backups restaurados desde copia permiten recuperar tokens e identificar objetos por etiqueta/serial.

Migración y compatibilidad

• Para migrar desde SoftHSM v1, compila con soporte de migración (–with-migrate) y usa la herramienta incluida.
• Comprueba compatibilidad de la ruta de instalación de la librería PKCS#11 con las aplicaciones que la referencian (p. ej., Firefox, OpenSSL con engine PKCS#11, servidores TLS).

Glosario (1 línea cada término)

• PKCS#11: estándar API para acceder a tokens criptográficos.
• Token: entidad lógica que contiene claves/objetos criptográficos.
• SO PIN: PIN del Security Officer para administración del token.
• User PIN: PIN usado por aplicaciones para operaciones de usuario.

Resumen final

SoftHSM ofrece una alternativa software útil para desarrollo, pruebas y algunos despliegues donde un HSM hardware no es imprescindible. Su compatibilidad con PKCS#11 facilita la integración con muchas aplicaciones. Sin embargo, para cargas críticas y requisitos regulatorios, se recomienda HSM hardware certificado.

Importante: trata los archivos de tokens y backups como secretos. Controla el acceso, cifra respaldos y documenta procedimientos de recuperación.

Anuncio corto

SoftHSM facilita probar y desarrollar integraciones PKCS#11 sin necesidad de hardware HSM. Instálalo en Ubuntu, inicializa tokens y realiza pruebas con pkcs11-tool o OpenSC.

Criterios de aceptación

• Instalación y pruebas completadas sin errores.
• Backups realizados y verificados.
• Políticas de acceso y rotación definidas.

Fin del artículo.