Migración de RSA Keon CA con nCipher

A continuación se describe cómo migrar de otra CA a EJBCA.

Introducción

Para demostrar los pasos específicos y ayudarle a reproducirlos, se seleccionó una CA específica: RSA Keon CA. La idea general de migración es la misma para otras implementaciones de CA.

La migración de otra CA a EJBCA consta de los siguientes pasos:

  • Migración de las claves de firma de las CA en nCipher HSM, lo que permite que las claves puedan ser utilizadas por EJBCA

  • Importación de la CA dentro de EJBCA

  • Importación de los certificados de usuario en EJBCA

A continuación se describe cómo migrar una instalación simple de KCA a EJBCA y se recomienda realizar primero una migración de prueba para familiarizarse con el proceso.

Entornos

Keon CA

Una configuración de KCA en un entorno de destino:

  • Servidor Windows 2003

  • KCA 6.5

  • Una CA raíz: TestKCARootCA

  • Una sub CA – TestKCASubCA

  • Claves de firma para las CA en la tarjeta PCI nCipher nShield

  • 5 usuarios emitidos por TestKCASubCA

Después de la instalación de este entorno, realice una copia de seguridad del mundo de seguridad nCipher, de los certificados CA y de los certificados de usuario.

EJBCA

Se elige un entorno de destino para EJBCA:

  • Ubuntu Linux 7.04 AMD64

  • JBoss 4.2.0, MySQL 5.0

  • EJBCA 3.5 o posterior; se recomienda 3.9

  • Una CA raíz: TestKCARootCA

  • Una sub CA – TestKCASubCA

  • Claves de firma para las CA en nCipher nShield PCI kort

  • 5 usuarios emitidos por TestKCASubCA

Migración de claves de firma de KCA

Este ejemplo asume que las claves de la CA de Keon se utilizan en un HSM de Thales/nCipher. Si se utiliza otro HSM, la migración de claves probablemente sea más sencilla, ya que PKCS#11 se puede usar inmediatamente. Sin embargo, tenga en cuenta que aún es necesario generar un objeto de certificado en el HSM para que Java pueda usar las claves.

Configurar PKCS#11 para nCipher

Para nCipher, el número de ranura es una ranura virtual con un nombre desconocido. Puede usar la ranura predeterminada omitiendo el número de ranura. Para usar nCipher PKCS#11, se deben configurar ciertos parámetros.

Cree el archivo /opt/nfast/cknfastrc con el siguiente contenido:

CKNFAST_LOADSHARING=1
CKNFAST_NO_ACCELERATOR_SLOTS=1
CKNFAST_NO_UNWRAP=1
CKNFAST_OVERRIDE_SECURITY_ASSURANCES=import

Claves de firma

Al instalar KCA, genera claves en el HSM nCipher. Estas claves están en formato nativo y solo KCA puede usarlas. No hay ninguna clave pública asociada al HSM.

Comencemos enumerando información general sobre el HSM:

C:\nfast\bin>enquiry
Server:
enquiry reply flags none
enquiry reply level Six
serial number B1BB-0EE9-3511
mode operational
version 2.23.6
speed index 440
rec. queue 422..622
level one flags Hardware HasTokens
version string 2.23.6cam6, 2.22.43cam8 built on Oct 13 2006
16:16:12
checked in 00000000431dca98 Tue Sep 06 18:58:00 2005
level two flags none
max. write size 8192
level three flags KeyStorage
level four flags OrderlyClearUnit HasRTC HasNVRAM HasNSOPermsCmd
ServerHasPollCmds FastPollSlotList HasSEE HasKLF HasShareACL
HasFeatureEnable Ha sFileOp HasPCIPush HasKernelInterface HasLongJobs
ServerHasLongJobs AESModuleKeys NTokenCmds LongJobsPreferred
code 0 type module 0
product name nFast server
device name
EnquirySix version 4
groups impath kx
feature ctrl flags none
features enabled none
version serial 0
Module #1:
enquiry reply flags none
enquiry reply level Six
serial number B1BB-0EE9-3511
mode operational
version 2.22.43
speed index 440
rec. queue 19..152
level one flags Hardware HasTokens
version string 2.22.43cam8 built on Oct 13 2006 16:16:12
checked in 00000000452f6a4d Fri Oct 13 12:28:29 2006
level two flags none
max. write size 8192
level three flags KeyStorage
level four flags OrderlyClearUnit HasRTC HasNVRAM HasNSOPermsCmd
ServerHasPollCmds FastPollSlotList HasSEE HasKLF HasShareACL
HasFeatureEnable Ha sFileOp HasPCIPush HasKernelInterface HasLongJobs
ServerHasLongJobs AESModuleKeys NTokenCmds LongJobsPreferred
code 7 type module 7
product name nC1003P /nC3023P
device name #1 PCI bus 7 slot 1
EnquirySix version 5
groups impath kx DHPrime1024
feature ctrl flags LongTerm
features enabled StandardKM
version serial 24
rec. LongJobs queue 18
SEE machine type de máquina PowerPCSXF
C:\nfast\bin>nfkminfo.exe
World
generation 2
state 0x17270000 Initialised Usable Recovery !PINRecovery
!ExistingClient RTC NVRAM FTO SEEDebug
n_modules 1
hknso 057731d6c635560900003fed89eba88c5082f2a1
hkm b08e66b01777fcf34dceb77c0684c8d1a071144e ( type DES3)
hkmwk 1d572201be533ebc89f30fdd8f3fac6ca3395bf0
hkre b0f5dbebedc703c6acd7685b261f6748bc4a9535
hkra 7368a945efc76505a19092c5115f493716de3172
hkmc 1d1e3fb769837be06e028bc038d1789ced2ac9e1
hkrtc 55f17755cae9ae49a588f154260306deeae1f5cc
hknv 82674f0623407fbaac5a3aaa0fc08346dff34f37
hkdsee 6df83c268c25939c307f61245235a2ac44e487ae
hkfto cae32a48bd1b9e68e606ae723f8dcb93eb4ee9ab
hkmnull 1d572201be533ebc89f30fdd8f3fac6ca3395bf0
ex.client none
k-out-of-n 1 /1
other quora m=1 r=1 nv=1 rtc=1 dsee=1 fto=1
createtime 2007-07-16 14:58:41
nso timeout 10 min
Module #1
generation 2
state 0x2 Usable
flags 0x0 !ShareTarget
n_slots 2
esn B1BB-0EE9-3511
hkml 5e43facc6aa39068092762d80a1954bded193b4b
Module #1 Slot #0 IC 25
generation 1
phystype SmartCard
slotlistflags 0x2 SupportsAuthentication
state 0x5 Operator
flags 0x10000 Passphrase
shareno 1
shares LTU(PIN)
error OK
Cardset
name ”oper”
k-out-of-n 1 /1
flags NotPersistent PINRecoveryForbidden(disabled) !RemoteEnabled
timeout none
card names ””
hkltu 3126f2b3cf7d9d53e3ba278a081ef471644298f8
gentime 2007-07-16 15:00:07
Module #1 Slot #1 IC 0
generation 1
phystype SoftToken
slotlistflags 0x0
state 0x2 Empty
flags 0x0
shareno 0
shares
error OK
No Cardset
No Pre-Loaded Objects

Para ver las claves utilizadas, ejecute el siguiente comando:

C:\nfast\bin>nfkminfo -k
Key list - 19 keys
AppName rsa-keon-ca- 65 Ident 1184599865281000
AppName rsa-keon-ca- 65 Ident 1184599867765000
AppName rsa-keon-ca- 65 Ident 1184599888484000
AppName rsa-keon-ca- 65 Ident 11845998900
AppName rsa-keon-ca- 65 Ident 1184599947937000
AppName rsa-keon-ca- 65 Ident 1184599969937000
AppName rsa-keon-ca- 65 Ident 1184599971843000
AppName rsa-keon-ca- 65 Ident 1184599974609000
AppName rsa-keon-ca- 65 Ident 1184599977718000
AppName rsa-keon-ca- 65 Ident 1184599980515000
AppName rsa-keon-ca- 65 Ident 1184599982765000
AppName rsa-keon-ca- 65 Ident 1184599985656000
AppName rsa-keon-ca- 65 Ident 1184599987625000
AppName rsa-keon-ca- 65 Ident 1184599989140000
AppName rsa-keon-ca- 65 Ident 1184599991234000
AppName rsa-keon-ca- 65 Ident 1184600151640000
AppName rsa-keon-ca- 65 Ident 1184600153609000
AppName rsa-keon-ca- 65 Ident 1184659106609000
AppName rsa-keon-ca- 65 Ident 1184659187875000

Hay varias claves, y no podemos determinar inmediatamente cuál es la clave de firma de la CA. Esto se puede determinar con el siguiente ejemplo:

C:\nfast\bin>pubkey-find.exe c:\kca.pem
input format cert
nCore hash d0196ea2e070315e9e162c28dcdc5a524bf6380d
unnamed
appname rsa-keon-ca- 65
ident 1184659106609000

Luego, agrega la clave pública correspondiente:

C:\nfast\bin>pubkey-find.exe --augment c:\kca.pem

A continuación, “mueva” la clave para que pueda ser utilizada por PKCS#11:

C:\nfast\bin>generatekey --retarget –no-verify pkcs11
13 : 40 : 30 WARNING: nfgk_debug_output is now deprecated (see manual).
from-application: Source application? (jcecsp, pkcs11, rsa-keon-ca- 65 )
[ jcecsp default jcecsp] > rsa-keon-ca- 65
from-ident: Source key identifier? ( 1184599865281000 , 1184599867765000 ,
1184599888484000 , 11845998900 ,
1184599947937000 , 1184599969937000 ,
1184599971843000 , 1184599974609000 ,
1184599977718000 , 1184599980515000 ,
1184599982765000 , 1184599985656000 ,
1184599987625000 , 1184599989140000 ,
1184599991234000 , 1184600151640000 ,
1184600153609000 , 1184659106609000 ,
1184659187875000 ) [ 1184599865281000 ]
> 1184659106609000
plainname: Key name? [] >
ERROR: plainname: key name unspecified
plainname: Key name? [] > kcaSign
key generation parameters:
operation Operation to perform retarget
application Application pkcs11
slot Slot to read cards from 0
verify Verify security of key no
from-application Source application rsa-keon-ca- 65
from-ident Source key identifier 1184659106609000
plainname Key name kcaSign
****************************************************
* WARNING: will not verify the security of the key *
****************************************************
Loading `oper':
Module 1 : 0 cards of 1 read
Module 1 slot 0 : `oper' # 1
Module 1 slot 0 :- passphrase supplied - reading card
Card reading complete.
Key successfully retargetted.
Path to key: c:\nfast\kmdata\local\key_pkcs11_uc3126f2b3cf7d9d53e3ba278a081
ef471644298f8-628484d430c6c0502fdb1a520fb84b9dc73c8372

Para usar la clave pública mediante PKCS#11, asocie un certificado a la clave. Para ello, tomamos el certificado real:

C:\nfast\bin>ckcerttool.exe -c oper -fc:\ca\kca.pem -k uc3126f2b3cf7d9d53e3ba27
8a081ef471644298f8-628484d430c6c0502fdb1a520fb84b9dc73c8372 -L kcaSign
Certificate found, processing...
Please enter the passphrase for ”oper” token (No echo set).
Passphrase:
Certificate successfully imported.
Run cklist to view your certificate object.
OK

A continuación, genere dos claves más para EJBCA. Una de ellas se usará para el cifrado interno y la otra para las pruebas del HSM. Esta generación debe realizarse como se describe en la Guía de Operaciones de EJBCA , utilizando las herramientas habituales de EJBCA. Genere una clave RSA de 2048 bits con el alias kcaDefault y una clave RSA de 1024 bits con el alias kcaTest.

keytool -generate -keystore NONE -storetype PKCS11-NFastJava -storepass foo123
-alias kcaDefault -keyalg RSA -keysize 2048
keytool -generate -keystore NONE -storetype PKCS11-NFastJava -storepass foo123
-alias kcaTest -keyalg RSA -keysize 1024

Utilizamos las herramientas EJBCA para obtener la asociación automática entre la clave privada y un certificado (ficticio), para que pueda ser utilizado a través del proveedor Java PKCS#11.

Importando la CA

Después de realizar la redirección de las claves para la CA raíz y la CA secundaria, puede usar las claves de EJBCA y comenzar a importar certificados de CA a EJBCA.

Tenga en cuenta que KCA no utiliza el mismo orden DN que EJBCA de manera predeterminada, por lo que si desea que el certificado emitido tenga exactamente el mismo aspecto, desactive la opción Usar orden DN LDAP de EJBCA después de la instalación.

Instale EJBCA como de costumbre con un ManagementCA, después de lo cual podrá importar las CA desde KCA desde el script de ayuda.

bin/ejbca.sh ca importca TestKCARootCA --hard --cp org.cesecore.keys.token.PKCS11CryptoToken --ctpassword foo123 --prop rootca.properties --cert TestKCARootCA-chain.pem

El archivo rootca.properties contiene:

defaultKey rootDefault
certSignKey rootSign
crlSignKey rootSign
testKey rootTest
pin foo123
sharedLibrary /opt/nfast/toolkits/pkcs11/libcknfast.so

Haga lo mismo para la SubCA:

bin/ejbca.sh ca importca TestKCASubCA --hard --cp org.cesecore.keys.token.PKCS11CryptoToken --ctpassword foo123 --prop rootca.properties --cert TestKCASubCA-chain.pem

El subca.properties contiene:

defaultKey subDefault
certSignKey subSign
crlSignKey subSign
testKey subTest
pin foo123
sharedLibrary /opt/nfast/toolkits/pkcs11/libcknfast.so

TestKCASubCA-chain.pem se crea con:

cat TestKCASubCA.pem TestKCARootCA.pem > TestKCASubCA-chain.pem

Ahora EJBCA tiene una CA raíz y una CA secundaria que utilizan las mismas claves de firma que KCA.

Importación de certificados de usuario

En EJBCA, el siguiente comando importa certificados de usuario:

bin/ejbca.sh ca importcert --username kca1 --password foo123 --caname TestKCASubCA -a ACTIVE -f user1.pem

El comando no importa información sobre la revocación. Es posible implementar la información completa de revocación mediante programación.

Puede crear su propia herramienta de migración y agilizar el proceso usando el código de la línea de comandos como plantilla. Se encuentra en modules/ejbca-ejb-cli/src/org/ejbca/ui/cli/ca/CaImportCertCommand.java .