Re: [Ejbca-develop] some problems / places for improvement

[Tomas G. <to...@pr...>]

Ah, you were running ejbca 3.0? EJBCA 3.1 has built-in support for nCiphe=
r HSM=20
as you have probably seen. Recent BC-provider allows us to pass the nCiph=
er HSM=20
as argumnet to the sign/crypt functions and it uses BC when that passed p=
rovider=20
does not implement a specific hash/crypto algorithm. So it works quite ni=
ce with
nCipher. One known issue is that SCEP does not work with the HSM right no=
w.

We have also built hardtoken support for using smart cards as a "low cost=
" hsm,=20
which works very nice and fast enough. It's not built into ejbca though b=
ut is=20
available through PrimeKey. We use a siemens card which can handle 2048 b=
it keys=20
and there is room for 12 keys, i.e. you can run 6 CAs on one smart card.

Cheers,
Tomas


Risto Laanoja wrote:
>>Your fix with the "BC" provider is however not correct, so=20
>>it's not included. When encrypting data encryption is done=20
>>with the public key, and that is=20
>>contained in the certificate, so encryption can be done=20
>>(should be) using BC.=20
>>Decryption is done with the private key which is locked in the HSM, so=20
>>decryption must be done with the provider for the HSM. You=20
>>can't fetch the=20
>>private key from the HSM.
>>BC has very nice support for using different provider by=20
>>passing the provider name. The default provider when using=20
>>soft tokens is BC btw.
>=20
>=20
> I did not figure out how to use BC for encrypted container management
> and other provider (custom possibly) for low-level crypto operations.
> But I plan to look at it again later.
>=20
>=20
>>Did you try using a hardware ca token?
>=20
>=20
> Yes, but with not-so-interesting API-s, resource leaks, some
> corner-cutting etc.
>=20
> Basically interfaces are following:
>=20
> Ejbca -> HardCAToken -> Crypto provider implementing only
> Signature.SHA1WithRSAEncryption and its aliases -> JDigiDoc library
> interface (see http://www.openxades.org/download.html - libraries for
> Estonian national ID card support. I had existing infrastructure workin=
g
> for "corporate legally binding digital signature" which has redundant
> network-attached (with special host computer) nShield HSM-s, and DigiDo=
c
> library interface was available to utilise it).=20
>=20
> It allowed to create CA management with FIPS level 3 HSM-s and multiple
> operator card sets - one persistent for general use, which is activated
> normally and protects level 2 CA keys and one card set for root CA key
> which needs special procedure to acticate and remains active until last
> hsm operator's card remains in hsm.
>=20
> In practice Jboss needs to be restarted nightly. After upgrading to 3.1
> I have to deal with it.
>=20
> I have also managed to run ejbca with local smartcard key storage, usin=
g
> same digidoc interface and Estonian national id-card. I do not remeber
> how it interfaced with opensc, so not sure if this would work with
> general PKCS #15 conforming (or with driver for opensc
> higher-level-operations) smartcards.
>=20
> Everyting is available but it is -khm- a bit shame to publish without
> polishing and expert's look. First j2ee and java project I'm digging
> with :)
>=20
>=20
> ---
> Risto
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=CCk
> _______________________________________________
> Ejbca-develop mailing list
> Ejb...@li...
> https://lists.sourceforge.net/lists/listinfo/ejbca-develop