Petr Spacek writes: > Definitely. We want to contribute the code to SoftHSMv2 instead > of reinventing the wheel, I'm sorry if it wasn't clear.
=> as you can see from my E-mail address I am not at all a member of the SoftHSMv2 team but I contributed a lot the code so this could be more than possible. > What we are trying to achieve: > > We want to integrate SoftHSMv2 in a way which separates key material > from the process using PKCS#11 interface (naturally this applies > only if euid != root) . > > The first idea is: > > - Write a thin library with PKCS#11 interface which serializes a > request from application and sends it via socket a daemon (running > under other user - separation happens here) => IMHO it is better to cut at the crypto library entry. BTW many PKCS#11 providers are designed this way, for instance hash operations are performed locally but private keys and anything which involves them are handled by the (remote) hardware. Another point: the pk11 open source code has a PKCS#11 spy, i.e., something which offers a PKCS#11 server on one side and a PKCS#11 client on the other. > - The daemon will unpack the request and call SoftHSMv2 library > (with necessary configuration etc.) > - <network_backend and crypto magic happens now inside SoftHSMv2> > - The response will be serialized and sent back from the daemon to > the caller => so you add a RPC layer to PKCS#11. The way PKCS#11 handles variable sized returned values will be a (trackable) problem. > And of course, this whole machinery has to serve multiple applications from > multiple users simultaneously. => IMHO you'll have to run multiple SoftHSMv2 processes. BTW storage backends are supposed to handle reasonable concurrent accesses. Regards Francis Dupont <[email protected]> _______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
