Offloading hashing e crittografia simmetrica a HSM

Question

Offloading hashing e crittografia simmetrica a HSM

#1 da (3 voti)

2

Quando si utilizza un HSM basato su (PKCS # 11) (per S / Mime o PGP) le operazioni di chiave pubblica per la firma o la decrittografia vengono eseguite dall'HSM in modo che la chiave non debba mai lasciare l'ambiente protetto. La maggior parte di queste operazioni (per firmare questa è la creazione del digest e per la crittografia questo è il codice simmetrico) può essere eseguita dall'host.

Tuttavia ho notato che la maggior parte delle implementazioni PKCS # 11 (anche le smart card lente) offrono anche cifrari simmetrici e persino hashing. Posso vedere i motivi per questo:

utilizzando l'interfaccia crittografica e l'implementazione hardware si può richiedere la conformità FIPS (hardened)
inviando tutti i bye al posto di un raw digest basato su un attaccante al componente che riduce gli attacchi con noti testi cifrati (per RSA)
consentendo all'HSM di generare o derivare la chiave di sessione non viene mai esposto (se questo è effettivamente supportato?)
sfruttando le fonti di numeri casuali hardware per la generazione di chiavi

Tuttavia ci sono alcune cose che non hanno senso, quindi mi chiedo quale sia la migliore pratica (principalmente per definire quale configurabilità dovrei offrire):

Non ho visto una "cifratura della chiave di sessione casuale con RSA e usarla per l'operazione AES" in PKCS # 11, quindi questa protezione prevista non esiste. O mi sto perdendo qualcosa?
Penso che per la firma dell'hash possa essere scaricato, ma sembra che la maggior parte di HSM non mi permetta di chiudere l'attacco 'raw digest' e non ho modo di limitare una chiave di firma ad un'operazione RSA (padding) sicura.
mentre HSM rivendica prestazioni migliorate dell'hardware, in particolare per le operazioni di massa, la maggior parte non riesce a stare al passo con le moderne CPU generiche (specialmente se i dati devono essere trasferiti tramite l'interfaccia di rete con messaggistica sicura all'HSM, solo co-processori o soluzioni PCI) può essere più veloce). Quindi c'è raramente un vantaggio in termini di velocità.

Quindi mi chiedo, con gli HSM, è comune consentire di specificare due provider o renderlo configurabile per ricadere sulle operazioni bulk locali? Ho controllato alcuni strumenti e molti di loro mi consentono di configurare il motore di crittografia per l'intera applicazione o operazione (come "hash + sign"). Non ho quasi mai visto un file di configurazione in cui posso dire "per RSA usare X e per SHA usare y". Sospetto che la maggior parte ricadrà all'hash predefinito (locale) se è selezionato un meccanismo di non-hashing? Le persone sono contente di questo?

encryption hsm pkcs11

posta eckes 21.07.2017 - 06:09

fonte

1 risposta

Leggi altre domande sui tag encryption hsm pkcs11

Integrità di WebSocket sicuro Come avviare OWASP Shepherd usando Docker? [chiuso]

score 3 · Answer 1

I have not seen a "encrypt random session key with RSA and use it to AES" operation in PKCS#11, so this expected protection does not exist. Or am I missing something?

No, non esiste alcuna operazione di questo tipo in PKCS # 11. Se vuoi farlo, devi costruirlo dalla funzione di base chiama te stesso: Genera una chiave simmetrica (su HSM per usare la sua origine entropica), avvolgi la chiave simmetrica con una chiave asimmetrica, fai la crittografia di massa.

I think for signing the hash can be offloaded, but it looks like most HSM do not allow me to close the 'raw digest' attack and have no way to restrict a signing key to a safe RSA (padding) operation.

I dispositivi PKCS # 11 supportano un elenco di meccanismi che specificano come vengono trattati i dati di input. I più comuni sono CKM_RSA_PKCS_PSS e CKM_RSA_PKCS per il canto e CKM_RSA_PKCS_OAEP o CKM_RSA_PKCS per la crittografia (più CKM_RSA_X_509 per RAA non elaborato).

Non c'è modo di limitare una chiave a un certo meccanismo per disabilitare completamente un meccanismo per il token. Se necessario, dovrai farlo a un livello inferiore e accedere direttamente al dispositivo tramite PC / SC (se possibile).

while HSMs claim hardware enhanced performance especially for the bulk operations most cannot keep up with modern general purpose CPUs (especially if the data has to be transferred over the network interface with secure messaging to the HSM) – so there is no speed advantage

Non esiste una risposta reale per questo, il termine HSM comprende una gamma molto ampia di dispositivi da numeri di cifre da due cifre a cinque cifre. I token o le smartcard in piccola scala saranno sicuramente più lenti quando si esegue AES rispetto a una CPU moderna, ma ci sono sicuramente dispositivi là fuori, che sono molto più veloci (controlla la categoria "Acceleratore SSL")