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

[Andreas S. <and...@ca...>]

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
> 


-- 

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Schülerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
    ---------    http://www.cardcontact.de
                 http://www.tscons.de
                 http://www.openscdp.org
                 http://www.smartcard-hsm.com