It could be that (undetailed) step "obtain parameters from hardware"
and/or other
indirect hardware calls caused by your OpenSSL calls makes the hardware
think the
key is now "spent" and can/must be deleted.
Hardware crypto is often designed to protect keys much more strictly
than software
crypto, because it is often used to ensure no "virus" can steal the
private key. FIPS
certification is also all about such strict protections.
So as the SSL handshake is outside both the FIPS sealed and hardware
sealed modules,
maybe you should look at a way of grabbing the public key from wherever
the SSL
code temporarily holds it for transmission in the handshake, thus
avoiding "suspect"
extra calls to the paranoid key protection systems.
On 08-12-2011 18:01, Odomae Bro wrote:
Thanks for the response Dave! I was using a FIPS compliant version of
openssl (0.9.8r) and anonymous DH for DTLS was broken with that
version. I am now working with 1.0.0.e and am able to get the
anonymous DH going. There is only one small problem.
We use the p and g from the client/server exchange, but the DH
private(say a) and public i.e. (A = g exp a mod p) is offloaded and
obtained from our hardware module. Once I get the keys, I copy them
into the dh_clnt->pub_key and dh_srvr_>pub_key in d1_clnt.c and
d1_srvr.c respectively.
The way I update the dh_*->pub_key is this:
DH_compute_key(...) // openssl call
.....
//obtain parameters from hardware
//then copy key into openssl structure for it to be exchanged
dh_clnt->pub_key = BN_bin2bn(pub_key_buff, modulus_len, dh_clnt->pub_key);
If I do this, the exchange stops after the GET_FINISHED_A. If I
remove the above line, the exchange completes and the client/server
exit gracefully.
Any ideas on why the copy back into the openssl structure would cause
issues?
On Mon, Dec 5, 2011 at 7:55 PM, Dave Thompson <dthomp...@prinpay.com
<mailto:dthomp...@prinpay.com>> wrote:
> From: owner-openssl-us...@openssl.org
<mailto:owner-openssl-us...@openssl.org> On Behalf Of Odomae Bro
> Sent: Saturday, 03 December, 2011 23:23
> I would like to generate my own DH private/public keys and
> have the client/server exchange these values. The problem I am
> having is that the openssl build I have is configured to use
> certificates. Hence the client side is getting the server's
> DH public value from the certificate. If I need to bypass this,
> how do I go about this?
I assume you are talking about SSL/TLS, if not describe further.
AFAIK OpenSSL has no _build_ option to use or not use certs;
that's a must-implement part of the protocol(s). OpenSSL
_applications_ can and often do have runtime options to use
certs/keys, or not; what applications are you concerned with?
What exactly do you mean by public value? TLS has ciphersuites
that use 'static' DH with publickey(s) in cert(s), but OpenSSL
doesn't support them. (It does enable static ECDH suites, but
it appears to me 'full' (both) static isn't implemented.)
> The client side is retrieving the server's public key value
> from s->session->sess_cert-> peer_dh_tmp i.e
> dh_srvr= s->session->sess_cert-> peer_dh_tmp
That is an 'ephemeral' aka 'temporary' key, NOT taken from
the cert (but *signed by* the server's cert/key unless
anonymous).OpenSSL does implement those. If you have a
DSA (resp ECDSA) cert, you could use the *parameters*
(P and G but ignore Q) from the key in the cert.
> So I thought I would set the s->session->sess_cert->
> peer_dh_tmp with my custom values, but I cannot find
>? the code on the server side where this is being set?
peer_tmp in the client is remembered from the ServerKeyExchange
message received from the server, which creates it in
ssl3_send_server_key_exchange from [ec]dh_tmp or _tmp_cb.
The *parameters* are set by SSL_[CTX_]set_[ec]dh_tmp[_callback].
The doc isn't entirely clear, but looking at the code
it appears to me that if the callback returns a DH or ECDH
*with* a keypair and SINGLE_[EC]DH_USE is not set,
that keypair is used; if you return only parameters, or
(always?) if parameters were pre-set, or if SINGLE_USE,
a random keypair is generated. So if you want to use your
own (pregenerated) DH or ECDH keys as ephemeral keys,
setting a callback that returns them and leaving SINGLE_USE
off should work. Of course the client and server keys must
share the same parameters; if you are not using the
parameters transmitted in the ServerKeyExchange to
do this, I presume you do it by some other means.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
<mailto:openssl-users@openssl.org>
Automated List Manager majord...@openssl.org
<mailto:majord...@openssl.org>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
