[Opendnssec-user] SmartCard-HSM as key store for DNSSEC

[Andreas Schwier]

A happy new year to everyone !

We've now completed the key backup / restore functionality for the 
SmartCard-HSM, including the required tools to ensure a proper key 
management.

The functionality is available via the sc-hsm-tool, that is part of the 
new 0.13 version of OpenSC [1].

So far we've tested with ods-hsmutil and ods-hsmspeed, however for a 
full opendnssec test setup we are lacking some basic DNSSEC expertise.

Maybe someone with a little more insight into DNSSEC would be interested 
to give it a test drive ?

Kind regards,

Andreas

[1] https://github.com/OpenSC/OpenSC/wiki/SmartCardHSM


asc at mozzarella:~/cbuild/opendnssec-1.3.12/libhsm/src$ ./ods-hsmutil -c 
../checks/conf-opensc.xml test default
Testing repository: default

Generating 512-bit RSA key... Failed
generate key pair: Unknown error

Generating 768-bit RSA key... Failed
generate key pair: Unknown error

Generating 1024-bit RSA key... OK
Extracting key identifier... OK, a9c2f82401deb576cbaa4399f788bc81
Signing (RSA/SHA1) with key... OK
Signing (RSA/SHA256) with key... OK
Signing (RSA/SHA512) with key... OK
Deleting key... OK

Generating 1536-bit RSA key... OK
Extracting key identifier... OK, abc0888ea8eb74e7bc52c119f9fd3f2f
Signing (RSA/SHA1) with key... OK
Signing (RSA/SHA256) with key... OK
Signing (RSA/SHA512) with key... OK
Deleting key... OK

Generating 2048-bit RSA key... OK
Extracting key identifier... OK, 77821db23c97b9588a042b8f8bf7e786
Signing (RSA/SHA1) with key... OK
Signing (RSA/SHA256) with key... OK
Signing (RSA/SHA512) with key... OK
Deleting key... OK

Generating 4096-bit RSA key... Failed
generate key pair: Unknown error

Generating 1024 bytes of random data... OK
Generating 32-bit random data... 2345982752
Generating 64-bit random data... 7323246965806626066

asc at mozzarella:~/cbuild/opendnssec-1.3.12/libhsm/src$ ./ods-hsmspeed -c 
../checks/conf-opensc.xml -r default
Opening HSM Library...
Generating temporary key...
Temporary key created: 4de762d8b80ae76dcbd526fc1bee7cc5
Signing 1 RRsets with RSA/SHA1 using 1 thread...
Signer thread #0 started...
Signer thread #0 done.
Signing done.
1 thread, 1 signatures per thread, 4.58 sig/s (RSA 1024 bits)
Deleting temporary key...


On 03/30/2012 08:45 PM, Andreas Schwier wrote:
> Dear Rickard,
>
> The chip is evaluated on EAL 5+ level against the Eurosmart PP, the
> operating system is evaluated on EAL 5+ level against the JavaCard PP.
>
> The combination of chip + os + applet is currently not certified, as the
> product is still under development. There is also currently no suitable
> PP for the kind of device we are going to build. SSCD-PP will not allow
> any kind of key backup and the Cryptographic Module PPs will require
> active components like a clock, not commonly available in smart card chips.
>
> If we actually will progress a composite CC evaluation depends on the
> market demand.
>
> For the replication/backup mechanism we envision two different mechanisms:
>
> 1) a key wrap/unwrap using a fixed key encryption key previously
> securely established in all cards of a cluster
> 2) a session key based key replication where devices in a cluster will
> need to authenticate against each other
>
> The first approach would have the advantage, that keys could be
> off-loaded to disk, if memory on the chip runs low.
>
> The second approach would use the existing device authentication key of
> a SmartCard-HSM to establish a secure session key for export from one
> and import into another SmartCard-HSM. In that scenario, the encrypted
> key would never be permanently stored outside the SmartCard-HSM as the
> session key is only used for one exchange.
>
> In EAC-PKI systems - for which the SmartCard-HSM has been designed
> initially - a key backup is no requirement, as keys would be regenerated
> and recertified if lost. Replication for load balancing is however a
> requirement. In that case the key will be generated in one
> SmartCard-HSM, replicated within the cluster and marked active only
> after the CA issued the certificate. For DNSSEC the workflow appears to
> be different.
>
> Andreas
>
>
> Am 30.03.2012 10:33, schrieb Rickard Bellgrim:
>>> We've designed a secure key store called SmartCard-HSM that implements
>>> secure generation, storage and use of asymmetric keys in a CC evaluated
>>> smart card (see flyer at [1]).
>> What CC Protection Profile have you evaluated against? Is there any
>> plan to also be FIPS 140-2 certified? Many customers also have
>> requirements on the FIPS level.
>>
>>> In a next step we want to support key replication among a cluster of
>>> SmartCard-HSMs in order to implement load balancing and key backup. We
>>> have a draft concept for it, but would like to cross-check with actual
>>> user requirements in the DNSSEC area.
>> You need to have a mechanism where you can export the key from one
>> card to an other, but also have it wrapped with an encryption key. The
>> initial trust between two cards must be authorized by the Security
>> Officer.
>>
>>  From the user perspective, a cluster must act in the same way as a
>> single card. The key must e.g. be replicated before the user think it
>> can use it. This is so that the user does not get load balanced to a
>> card which is missing the key once signing.
>>
>> // Rickard
>