PKI e firme con chiavi protette.

L'HSM protegge una chiave di firma entro il confine previsto; non decide da solo se un pacchetto software debba essere approvato. Per questo colleghiamo le chiamate di firma ad applicazioni identificate, autorizzazioni e approvazioni. Nel code signing, artefatto e approvazione vengono collegati tra loro, in modo che le modifiche successive siano riconoscibili. Il software di CA e il provider dell'HSM devono supportare congiuntamente l'algoritmo utilizzato e l'accesso alle chiavi. Trust store, verifica dello stato e rinnovo vengono testati con controparti rappresentative.

Una smart card di amministratore smarrita, certificati scaduti e una issuing CA compromessa sono eventi diversi. Predisponiamo procedure adeguate e testiamo il percorso di ripristino concordato. Il collaudo documenta, tra l'altro, emissione, rinnovo, revoca e richieste non valide. Profili di certificato, classi di dispositivo e relazioni di fiducia esistenti aiutano a pianificare un esercizio parallelo durante la migrazione.

Verifichiamo l'integrazione supportata dal rispettivo prodotto, ad esempio tramite un CNG Key Storage Provider, PKCS #11 o un provider Java. Un nome di algoritmo identico da solo non garantisce la compatibilità: devono coincidere anche meccanismi, attributi delle chiavi, padding e versione del provider. Per le autorità di certificazione esistenti si chiarisce se è ammesso un trasferimento delle chiavi oppure se serve una nuova CA con una fase di transizione. La fiducia dei sistemi collegati viene considerata esplicitamente nel test.

La pipeline non dovrebbe possedere in modo permanente una chiave di produzione liberamente utilizzabile. Separiamo build e approvazione della firma, associamo i job a un sistema identificato e stabiliamo quali artefatti possono essere firmati con quale chiave. Marca temporale, evidenza dell'hash dell'artefatto e logging vengono previsti in base al formato di firma. In questo contesto l'HSM è un componente di protezione: la verifica del codice e la decisione sulla pubblicazione restano compiti del processo di sviluppo e approvazione.

Un'organizzazione gestisce già certificati per dispositivi, utenti e servizi interni. OTOKO® rileva profili dei certificati, distribuzione e catene di fiducia e prova l'integrazione HSM prevista dapprima al di fuori della produzione. Successivamente pianifichiamo la migrazione, compresi rinnovo, informazioni di revoca e limiti di rollback. Prima del passaggio di consegne vengono verificate controparti concrete: un certificato emesso rappresenta un successo solo quando l'autenticazione, l'accesso al servizio o la verifica della firma funzionano nel sistema previsto.