Re: [Ejbca-develop] SmartCard-HSM as remote key store / Was:Re: Problem Creating a CVC CA in ejbca 6.2.0

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

Thanks Andreas,

It would be great fun to test. Honestly though, it will be hard to get 
the time to do it without business driver at this time unfortunately.
There's just too much to do just to have business running.

Cheers,
Tomas

On 2014-07-28 10:11, Andreas Schwier wrote:
> Hi Tomas,
>
> let me know if you would like to get some SmartCard-HSM samples.
>
> I'm not really a J2EE expert, so I'm probably not in position to code that.
>
> Andreas
>
> On 07/22/2014 12:48 PM, Tomas Gustavsson wrote:
>>
>> So for EJBCA a new CryptoToken is probably needed, in order to use your
>> the provider (sine it is not generic PKCS#11).
>>
>> That's a very isolated code though, and can be done in an almost
>> pluggable way I think.
>>
>> Cheers,
>> Tomas
>>
>> On 2014-07-21 14:43, Andreas Schwier wrote:
>>> After the client connects to the server, the server reads the device and
>>> device issuer CV-certificates from the SmartCard-HSM and verifies the
>>> integrity and authenticity of the device authentication public key. This
>>> public key is then used to establish symmetric session keys using ECDH
>>> and an ephemeral key pair at the server. The session keys are
>>> subsequently used to protect all APDU exchange between the server and
>>> the remote device. This happens in the OCF layer and is transparent at
>>> the JCE layer.
>>>
>>> Using this mechanism, the CA server knows that he talks to an identified
>>> and authentic remote device. Encryption and MACing in the secure channel
>>> protects all data exchanged, in particular data to be signed by the
>>> private key in the remote device.
>>>
>>> CV certificates are used because they are considerably smaller that
>>> X.509 certificates.
>>>
>>> The mechanics are similar to TLS server authentication, with the smart
>>> card as the server and X.509 certificates replaced by CV-certificates.
>>> The protection is actually on the APDU layer, HTTP is just used as
>>> transport channel to carry APDU exchange.
>>>
>>> Andreas
>>>
>>> On 07/21/2014 01:45 PM, Andreas Kuehne wrote:
>>>> Hi Andreas,
>>>>> Would be interesting to get something like this integrated with EJBCA.
>>>>>
>>>>> That shouldn't be too complicated: The server side is just a small
>>>>> servlet that provides the APDU channel via HTTP to the device on the
>>>>> client side. The servlet talks to OCF on the server and a JCE Provider
>>>>> on top of it.
>>>>>
>>>>> The CA would just need to access the private key operation via JCE.
>>>> I would go with any security enhancement ... but dtmo the
>>>> cv-certificates do make sense when two cards interact. If one and is a
>>>> server with 'usual' security level it does not provide any benefit, does
>>>> it? Just just a strong link to chain but leave the other links weak as
>>>> they are ...
>>>>
>>>> Greetings,
>>>>
>>>> Andreas Kuehne
>>>>
>>>>
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck
>> Code Sight - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Ejbca-develop mailing list
>> Ejb...@li...
>> https://lists.sourceforge.net/lists/listinfo/ejbca-develop
>>
>
>