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@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@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
_______________________________________________
Opendnssec-user mailing list
[email protected]
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
