Encriptación HSM: funcionamiento e claves privadas (2026)

A seguridade das transaccións dixitais repousa nun compoñente moitas veces descoñecido polas direccións informáticas: o Hardware Security Module (HSM). Este dispositivo hardware dedicado xera, almacena e protexe as claves criptográficas sen nunca expoñelas ao contorno de software externo. Mentres que os ciberataques dirixidos ás infraestruturas PKI progresaron un 43 % entre 2023 e 2025 segundo o informe ENISA Threat Landscape 2025, comprender o funcionamento da encriptación HSM convértese nunha cuestión estratéxica para calquera empresa que xestione firmas electrónicas cualificadas, transaccións bancarias ou intercambios de datos sensibles. Este artigo descifra a arquitectura dun HSM, o ciclo de vida das claves privadas, os protocolos criptográficos implementados, e os criterios de selección para as organizacións B2B.

Arquitectura hardware dun HSM: un cofre criptográfico

Un HSM é, por definición, un dispositivo físico inviolable (tamper-resistant). A diferenza dunha solución software, integra mecanismos de detección de intrusións que desencadean o borrado automático das claves cando se detecta calquera tentativa de violación física (mecanismo denominado zeroization).

Compoñentes internos e illamento seguro

A arquitectura interna dun HSM repousa en varias capas complementarias:

• Procesador criptográfico dedicado: executa as operacións de encriptación (RSA, ECDSA, AES, SHA-256) de forma illada do sistema anfitrión.
• Xerador de números aleatorios hardware (TRNG): produce entropía verdadeira, indispensable para a solidez das claves xeradas — os TRNG hardware superan amplamente os PRNG software en termos de impredictibilidade.
• Memoria segura non volátil: almacena as claves mestras nunha zona fisicamente protexida, inaccesible desde o exterior incluso en caso de desmontaxe.
• Envolvente inviolable (tamper-evident enclosure): calquera tentativa de apertura desencadea unha alarma e o borrado dos secretos.

Os HSM están certificados segundo as normas FIPS 140-2/140-3 (niveis 2 a 4) publicadas polo NIST americano, e Common Criteria EAL 4+ para os usos europeos máis esixentes. Un HSM de nivel FIPS 140-3 nivel 3, por exemplo, impón autenticación multifactor para calquera acceso ás claves e resiste ataques físicos activos.

Modos de despliegue: on-premise, PCIe e cloud HSM

Tres formas físicas coexisten no mercado B2B:

1. HSM de rede (appliance): caixa rack conectada á rede local, compartida entre varios servidores de aplicación. Tipicamente utilizada por provedores de servizos de confianza (PSCo/TSP) certificados eIDAS.
2. Tarxeta PCIe HSM: módulo integrado directamente nun servidor, ofrecendo mellores latencias para aplicacións con alto volume de firmas.
3. Cloud HSM: servizo xestionado ofrecido por provedores en nube (Azure Dedicated HSM, AWS CloudHSM, Google Cloud HSM). O hardware permanece fisicamente dedicado ao cliente pero está aloxado no datacenter do provedor — pertinente para empresas que desexen evitar a xestión hardware mantendo control exclusivo sobre as súas claves.

A elección entre estes modos condiciona directamente o nivel de conformidade alcanzable co regulamento eIDAS 2.0, nomeadamente para as firmas cualificadas (QES) que esixen un dispositivo de creación de firma cualificado (QSCD) — un HSM certificado constitúe o QSCD por excelencia.

Ciclo de vida das claves privadas nun HSM

O valor real dun HSM resida na súa capacidade de xestionar a integridade do ciclo de vida das claves criptográficas sen que unha clave privada "saia" nunca en claro do seu perímetro hardware.

Xeración e inyección das claves

A xeración de claves no seo do HSM é fundamental. Calquera clave xerada no exterior e despois importada presenta un risco residual relacionado co seu tránsito nun contorno non controlado. As boas prácticas impoñen polo tanto:

• Xeración do par de claves (pública/privada) directamente no HSM mediante o TRNG integrado.
• A clave privada nunca abandona o perímetro hardware do HSM — nin sequera os administradores do sistema teñen acceso en claro.
• A clave pública, só ela, é exportada para ser integrada nun certificado X.509 expedido por unha Autoridade de Certificación (CA).

Certos protocolos como PKCS#11 (estándar OASIS) ou JCE (Java Cryptography Extension) permiten ás aplicacións de negocio invocar as operacións criptográficas do HSM mediante chamadas API estandarizadas, sen nunca manipular directamente as claves.

Operacións criptográficas: firma, desencriptación, derivación

Cando un usuario asinará un documento, eis o fluxo técnico exacto:

1. A aplicación calcula a pegada dixital (hash) do documento empregando unha función de hachado (SHA-256 ou SHA-384).
2. O hash é transmitido ao HSM mediante a interface PKCS#11 ou CNG (Cryptography Next Generation baixo Windows).
3. O HSM asinará o hash internamente coa clave privada RSA-2048 ou ECDSA P-256, segundo a configuración.
4. A firma dixital é devolva á aplicación — nunca a clave en si.

Este principio de operación en caixa negra garante que incluso unha compromisión total do servidor de aplicación non permite a un atacante extraer a clave privada.

Copia de seguridade, rotación e destrución das claves

O ciclo de vida completo dunha clave comprende:

• Copia de seguridade encriptada: as claves poden ser exportadas en forma encriptada (Wrapped Key) empregando unha clave de encriptación de claves (KEK), ela mesma almacenada noutro HSM mestre — principio da Key Ceremony documentado polas CA.
• Rotación periódica: recomendada cada 1 a 3 anos segundo a duración de vida dos certificados e o nivel de risco. O regulamento eIDAS 2.0 e as políticas ETSI TS 119 431 enmarcan estas duracións para os TSP.
• Revogación e destrución: ao final da vida, a clave é destruída por zeroization — operación irreversible garantindo que ningunha reconstrución é posible.

Para as organizacións que desexen comprender como a firma electrónica cualificada se apoia nestes mecanismos, o HSM constitúe o corazón técnico do QSCD imposado por eIDAS.

Protocolos criptográficos e estándares soportados polos HSM

Un HSM empresarial moderno soporta un catálogo amplo de primitivas e protocolos criptográficos.

Algoritmos asimétriques e simétricos

| Familia | Algoritmos comúns | Uso típico | |---|---|---| | Asimétricas | RSA-2048/4096, ECDSA P-256/P-384, Ed25519 | Firma dixital, intercambio de claves | | Simétricas | AES-128/256-GCM, 3DES (legacy) | Encriptación de datos, envoltura de claves | | Hachado | SHA-256, SHA-384, SHA-512 | Integridade, pegada de documento | | Poscuántica (PQC) | CRYSTALS-Kyber, CRYSTALS-Dilithium (NIST FIPS 203/204) | Transición criptográfica 2026+ |

A integración dos algoritmos poscuánticos (PQC) é un asunto de actualidade candente: o NIST finalizou en 2024 os primeiros estándares PQC (FIPS 203, 204, 205), e varios fabricantes de HSM (Thales, nCipher/Entrust, Utimaco) ofrecen xa en 2026 firmware soportando estes algoritmos en modo híbrido RSA+Kyber.

Interfaces e protocolos de integración

O ecosistema de integración dun HSM repousa en varios estándares abertos:

• PKCS#11: interface C API máis difundida, soportada por OpenSSL, EJBCA, e a maioría dos servidores de aplicacións Java.
• Microsoft CNG/KSP: integración nativa no ecosistema Windows Server / Active Directory Certificate Services.
• KMIP (Key Management Interoperability Protocol): estándar OASIS para a xestión centralizada de claves entre HSM heteroxéneos — particularmente útil en arquitecturas multi-nube.
• API REST proprietarias: os cloud HSM modernos expoñen API REST para unha integración DevOps fluída (Infrastructure as Code, provedores Terraform).

O dominio destas interfaces é indispensable para integrar un HSM nunha plataforma de firma electrónica para empresas con alto volume.

Criterios de selección dun HSM para empresas B2B en 2026

Ante unha oferta de mercado diversificada, varios criterios obxectivos deben guiar a decisión de compra ou subscrición a un HSM-as-a-Service.

Nivel de certificación e conformidade regulatoria

Para un uso no contexto da firma electrónica cualificada (eIDAS) ou de procesos bancarios sometidos a PSD2/DSP2:

• FIPS 140-3 nivel 3 como mínimo para datos de carácter persoal ou financeiro sensible.
• Certificación Common Criteria EAL 4+ con perfil de protección EN 419221-5 para os QSCD eIDAS — é o estándar de referencia das listas de confianza europeas (Trusted Lists ETSI TS 119 612).
• Cualificación ANSSI para as entidades francesas sometidas a regulacións sectoriais específicas (defensa, operadores de importancia vital).

Rendemento, alta dispoñibilidade e TCO

Os HSM de rede de alta gama (Thales Luna Network HSM 7, Entrust nShield Connect XC) mostran rendementos de varios millares de operacións RSA-2048 por segundo, con configuracións activo-activo para alta dispoñibilidade. O TCO en 5 anos dun HSM on-premise inclúe: hardware, mantemento, persoal cualificado, e xestión das Key Ceremonies — elementos que fan moitas veces o Cloud HSM máis atractivo para PYMEs e ETI.

Para as organizacións que avalan o retorno da inversión global da súa infraestrutura de firma, o uso dun calculador ROI dedicado á firma electrónica permite cifrar con precisión as ganancias operacionais asociadas á segurización por HSM.

Gobernanza das claves e control de acceso

Un HSM só val pola calidade da súa gobernanza:

• Principio dos M-of-N: calquera operación sensible (xeración de clave mestre, inicialización) require a presenza simultánea de M administradores entre N designados — tipicamente 3 entre 5.
• Xornais de auditoría inmutables: cada operación criptográfica é trazada en logs horodatados e asinados, esixencia do RGPD (art. 5.2, responsabilidade) e dos referentes ETSI.
• Separación de funcións: administrador HSM, operador de claves, e auditor son funcións distintas — conforme ás esixencias das políticas de certificación ETSI EN 319 401.

A comprensión das esixencias do regulamento eIDAS 2.0 é indispensable para calibrar correctamente a gobernanza das claves nun contexto de firma cualificada europea.

Marco legal aplicable á encriptación HSM na empresa

O despliegue dun HSM para a xestión de claves criptográficas inscríbese nun corpus regulatorio denso, á encrucillada do dereito da firma electrónica, da protección de datos persoais e da ciberseguridade.

Regulamento eIDAS n° 910/2014 e revisión eIDAS 2.0

O regulamento eIDAS establece as condicións técnicas e xurídicas das firmas electrónicas cualificadas (QES). O seu artigo 29 impón que os dispositivos de creación de firma cualificados (QSCD) garantan a confidencialidade da clave privada, a súa unicidade, e a imposibilidade de derivala. Estas esixencias técnicas só poden ser satisfeitas por un HSM certificado segundo o perfil de protección EN 419221-5 ou equivalente. A revisión eIDAS 2.0 (Regulamento UE 2024/1183, en vigor desde maio de 2024) reforza estas obrigacións coa introdución do carteira europeo de identidade dixital (EUDIW), que repousa el tamén en QSCD conformes.

Normas ETSI aplicables

A familia de normas ETSI encadra con precisión as prácticas dos provedores de servizos de confianza (TSP):

• ETSI EN 319 401: esixencias xerais de seguridade para os TSP, incluíndo a xestión dos HSM e a separación de funcións.
• ETSI EN 319 411-1/2: políticas e prácticas de certificación para as CA expedindo certificados cualificados.
• ETSI EN 319 132: perfil XAdES para a firma electrónica avanzada — as operacións de firma fan apel aos HSM.
• ETSI TS 119 431-1: esixencias específicas aos servizos de firma a distancia (Remote Signing), onde o HSM é operado polo TSP pola conta do signatario.

Código civil francés (artigos 1366-1367)

O artigo 1366 do Código civil recoñece o valor xurídico do escrito electrónico cando é posible identificar o seu autor e se garante a súa integridade. O artigo 1367 asimila a firma electrónica cualificada á firma manuscrita. A protección da clave privada por HSM é o mecanismo técnico que torna esta presunción de imputabilidade irrebutible ante as xurisdicións.

RGPD n° 2016/679

Cando un HSM trata claves vinculadas á identidade de persoas físicas (certificados cualificados nominativos, logs de auditoría incluíndo datos de identificación), o RGPD aplícase plenamente. O artigo 25 (privacy by design) impón integrar a protección de datos desde o deseño — o HSM responde a esta esixencia tornando tecnicamente imposible o acceso ás claves privadas fora do marco operacional definido. O artigo 32 esixe a aplicación de medidas técnicas apropriadas: o HSM constitúe o estado da arte en materia de protección criptográfica.

Directiva NIS2 (UE 2022/2555)

Transposta ao dereito francés pola lei do 15 de abril de 2025, a directiva NIS2 impón aos operadores esenciais e importantes (OES/OEI) aplicar medidas de xestión de riscos incluíndo explicitamente a seguridade da cadea de subministración criptográfica. O recurso a HSM certificados para a protección das claves de firma e de encriptación inscrívese directamente neste marco, nomeadamente para os sectores sanidade, finanzas, enerxía e infraestrutura dixital.

Responsabilidades e riscos xurídicos

Unha compromisión de clave privada resultante dunha ausencia de HSM ou dunha configuración insuficiente pode comprometer a responsabilidade civil e penal do responsable do tratamento, expor a organización a sancións CNIL (ata o 4 % do CA mundial), e invalidar retroactivamente o conxunto das firmas emitidas coa clave comprometida. A carencia de xornalización das operacións HSM constitúe ademais unha non-conformidade caracterizada aos referentes ETSI e RGPD.

Escenarios de uso: o HSM en acción nas empresas B2B

Escenario 1 — Plataforma de firma cualificada para un grupo industrial multi-sedes

Un grupo industrial europeo composto por 15 filiais e xestionando aproximadamente 4 000 contratos proveedores ao ano decide centralizar a súa cadea de firma electrónica cualificada. O equipo de seguridade despliega dous HSM de rede en configuración alta dispoñibilidade activo-activo en dous datacenters distintos (estratexia de resilencia xeográfica). As claves de firma cualificadas de cada entidade xurídica son xeradas e almacenadas exclusivamente nos HSM, accesibles mediante unha interface PKCS#11 exposta á plataforma de firma SaaS.

Resultados observados tras 12 meses: cero incidentes de seguridade vinculados á xestión das claves, conformidade total na auditoría eIDAS realizada por un organismo de avaliación de conformidade (CAB) acreditado, e redución do 67 % nos prazos de firma contractual (de 8,3 días en media a 2,8 días). O custo total de despliegue HSM foi amortizado en 14 meses grazas ás ganancias de productividade e á supresión dos procesos papel residuais.

Escenario 2 — Bufete de asesoría xurídica e xestión da firma de mandatos clientes

Un bufete de avogados de negocios de 45 colaboradores, tratando expedientes de fusión-adquisición e contencioso mercantil, busca asegurar os seus fluxos de firma de mandatos, cartas de misión e actos de procedemento. Ante a imposibilidade de utilizar un HSM on-premise (ausencia de equipo IT dedicado), o bufete subscrebe a un servizo Cloud HSM integrado nunha solución de firma electrónica para bufetes xurídicos.

Cada socio dispón dun certificado cualificado cuxa clave privada é almacenada no HSM dedicado do provedor, certificado FIPS 140-3 nivel 3 e referenciado na lista de confianza europea. O bufete benefíciase dunha trazabilidade completa das operacións (logs horodatados, exportables para as necesidades da proba en caso de contencioso), sen ningún tipo de infraestrutura hardware a xestionar. A redución do tempo administrativo vinculado á xestión documental é estimada en 3,5 horas por colaborador e por semana segundo os benchmarks sectoriais dos bufetes comparables.

Escenario 3 — Establecemento de sanidade e protección de datos de prescrición electrónica

Un agrupamento hospitalario duns 1 200 leitos implementa a prescrición médica electrónica segura (e-prescrición) conforme ás esixencias da ANS (Axencia do Numérico en Sanidade) e do marco Mon Espace Santé. As prescricións deben ser asinadas cun certificado profesional de sanidade (CPS) cuxa clave privada en ningún caso pode ser exposta nos postos de traballo dos prácticos.

A DSI despliega un HSM certificado Common Criteria EAL 4+ integrado na súa infraestrutura de xestión de identidades (IGC interna). As claves CPS dos médicos son almacenadas no HSM; os prácticos se autentican mediante tarxeta a peca + PIN para desencadear a operación de firma delegada ao HSM. Este mecanismo, conforme á regulación eIDAS e ás normas ETSI, reduce do 89 % o risco de roubo de clave con respecto a un almacenamento software en posto, e permite unha revogación centralizada en menos de 5 minutos en caso de saída ou perda de tarxeta.

Conclusión

A encriptación HSM constitúe a pedra angular de calquera infraestrutura de firma electrónica cualificada e de xestión segura das claves privadas na empresa. Combinando illamento hardware, algoritmos criptográficos probados, gobernanza estrita das claves e conformidade aos estándares FIPS 140-3, Common Criteria e ETSI, o HSM ofrece un nivel de protección sen igual fronte ás ameazas actuais e ás esixencias regulatorias europeas. Bien opte pola implementación on-premise, unha tarxeta PCIe ou un Cloud HSM xestionado, o esencial é aliñar a súa elección co seu nivel de exposición ao risco e as súas obrigacións legais eIDAS, RGPD e NIS2.

Certyneo integra nativamente HSM certificados na súa infraestrutura de firma electrónica cualificada, permitíndolle beneficiarse desta seguridade de nivel empresa sen complexidade operacional. Pronto a segurizar os túas fluxos documentarios cunha solución conforme e certificada? Comeza gratuitamente en Certyneo ou consulta os nosos prezos para atopar a oferta adaptada á túa organización.