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

[Andreas Schwier]

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


-- 

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