4

If I have a valid (verifiable) certificate C_K_s that links the server key K_s to "www.example.com", is it possible to :

  • use K_s to sign K_d, and let S_K_d be this signature
  • use K_d as the TLS server key

when a TLS client connects, I would:

  • show C_K_s to establish that the official key is K_s
  • then during session key negotiation:
    • show S_K_d to establish that the actual key is K_d
    • sign the pairwise private key, or server DHE key, with K_d

I want TLS clients to tell users that the server key is K_s.

K_s is the key I will print, that users can check, etc. (Users do not need to know about K_d.)

  • s is for static: K_s would rarely change, can be stored off-line and/or stay encrypted. For example, in a secured configuration, K_s could be stored in a special mass storage that can only be read once after each reboot (I believe this property can be obtained f.ex. with a TPM).
  • d is for dynamic: K_d can change often, must be in clear-text in server memory at all times.

I just want to be able to change my real server K_d as often as I want, without either the CA, Perspective, some "SSL Observatory"... knowing about it because the official signing key is really K_s. The official certificate is C_K_s so Certificate Patrol should not store only C_K_s and not tell when C_K_d changes.

Would it be possible to emulate this behaviour using a fixed (precomputed) DHE key as K_d?

Clarification about the term "certificate"

I used the term "certificate" for the validation of K_d using K_s, and this unfortunate wording has created some confusion.

The TLS server would only possess K_d (not K_s), so a link between K_s and K_d is needed, and I called that link a "certificate", but it is just a signature of K_d by K_s.

curiousguy
  • 5,028
  • 3
  • 25
  • 27
  • What do I have to read in order to understand this question? ;) I'll take any links you suggest. Are you assuming working knowledge of how TLS negotiation works? Now that I see your update this doesn't appear to be a PKI question on End Entities... (or is it?) – makerofthings7 Jun 18 '12 at 00:45
  • Following your edit, note that there is never any point signing *just* a pub key (see [this question](http://security.stackexchange.com/q/14479/2435)): you always sign the association between the key and something, which effectively makes the result a cert. Overall, it's not clear what your scheme would improve compared with using the key in the cert directly: losing the private key for K_d would still allow an attacker to impersonate your server, without the private key for K_s, unless you end up implementing what would equate to a complex PKI system (including mechanism for revocation). – Bruno Jun 18 '12 at 11:31
  • @Bruno I could say: "by that the signature, the signer certifies that..." Of course any signature certifies a *statement of fact*, but here C_K_s is a regular TLS/X.509 certificate, and S_K_d need not all these attributes. During RSA_DHE, does the DHE key verification involves a certificate signing the DHE key? – curiousguy Jun 18 '12 at 13:16
  • @makerofthings7 "_Are you assuming working knowledge of how TLS negotiation works?_" Not really, superficial knowledge about TLS connection establishment should be more than enough (I don't have a really deep knowledge of the TLS protocol either). I will edit my question again to make clearer. – curiousguy Jun 18 '12 at 13:19
  • @curiousguy, yes the DHE parameters are signed (together with the hello random value) using the server's private key (matching the server cert), see Appendix F.1.1.3 (link in my answer). Unfortunately, superficial knowledge of TLS will not be enough. (How far are you willing to modify client SSL/TLS stacks for this, btw?) – Bruno Jun 18 '12 at 13:42
  • @Bruno "_yes the DHE parameters are signed (together with the hello random value) using the server's private key_" does this signature constitute a certificate? "_(How far are you willing to modify client SSL/TLS stacks for this, btw?)_" My question is "what can be done within the existing standard". The intent is to be compatible with existing tools. – curiousguy Jun 18 '12 at 13:52
  • "*does this signature constitute a certificate?*" not really, it's part of the handshake mechanism ([Server Key Exchange Message](http://tools.ietf.org/html/rfc4346#section-7.4.3)). Am I right in assuming that the specific threat you want to be protected against would be the theft of the private key used by the server? If so, do you realise it doesn't really help, unless you put some time limit on the validity of the temporary key pair? – Bruno Jun 18 '12 at 14:06
  • @Bruno I want to limit damages in case the server is compromised. (A compromised server is a serious security even in any case.) I do not really trust the server administrator ability to detect a break-in (my intuition is that if he could, then he should also be able to prevent it) and the front-page stories of intrusions in some well-known companies, which went on for a long time without detection confirm my intuition. Nor do I trust certificate revocation processes much (and recent changes to disable revocation checking in browsers confirm my intuition). The only way seems a short-lived key. – curiousguy Jun 20 '12 at 03:51
  • @Bruno "_yes the DHE parameters are signed (together with the hello random value)_" the hello value kills my silly "fixed DHE" idea, because the DH server key signature couldn't be precomputed in this case. – curiousguy Jun 20 '12 at 06:33

2 Answers2

2

Certificates have a purpose field. So if you let a well known certification authority sign your server key, the resulting certificate will only be valid for servers.

In order to sign other keys, you need to get a certificate with the certificate signing purpose. In theory there is an extension which limits CAs to a domain, but it is hardly used. Therefore there are very high requirements for CAs.

Hendrik Brummermann
  • 27,118
  • 6
  • 79
  • 121
  • I only want to use the K_s TLS key to authenticate a TLS key exchange with a TLS client. With TLS, an RSA key can be used to sign a private key directly, or a DH key, or (as Bruno says) another RSA key according to RFC 4346... in any case, the aim is to obtain a shared private secret between a TLS server and a TLS client, just with a additional intermediate level. How is that _not_ the normal purpose of a server key? – curiousguy Jun 15 '12 at 23:06
  • @curiousguy, Hendrik is referring to certificate validation according to RFC 3280/RFC 5280, which is normally used by browsers. That's what validates the certificate chain, and says what the keys in the certificate may be used for (it's mostly from an administrative point of view, but that's the point of the PKI). There are key usage extensions and so on. Here, it's the [basic constraint](http://tools.ietf.org/html/rfc5280#section-4.2.1.9) extension that you'd need for your cert to be a CA cert, being able to issue your temporary certs (although that's not exactly what you seem to want to do). – Bruno Jun 16 '12 at 11:20
  • @Bruno Yes, I understand that I could have an intermediate certificate that's essentially a CA for only one domain, with about the same powers has a *.domain cert, and this is exactly what I do not want. I want the certificate for my domain to indicate K_s and nothing else, and to introduce K_d not before the process of pairwise key agreement. – curiousguy Jun 17 '12 at 23:26
  • My question was perhaps badly worded, I am editing it. – curiousguy Jun 17 '12 at 23:27
2

What you're describing sounds similar to the use of temporary RSA key exchange, as described in Appendix F.1.1.2 of RFC 4346 (TLS 1.1) (also in RFC 2246, TLS 1.0).

I have never seen it used (but others may have). However, there seem to be a few inconsistencies in the specification on this subject. In particular, this appendix says that "[it] may be a temporary RSA key sent in a server key exchange message", but Section 7.4.3 (Server Key Exchange Message) says: "It is not legal to send the server key exchange message for the following key exchange methods RSA, DH_DSS, DH_RSA", which leaves the DHE cipher suites (and DH_anon). I must admit I'm not quite sure how this would work then, considering that with DHE_RSA and DHE_DSA, the DHE parameters are still signed using the certificate's key. This may explain why the mention of temporary RSA keys has disappeared from TLS 1.2.

Your other suggestion, about fixed DHE parameters, removes the "ephemeralness" of DHE, so that's rather about fixed DH; not all stacks support it. In addition, you'd still want the RSA/DSA key in the certificate itself to be used for the authentication anyway.

More fundamentally, it sounds like the potential vulnerability you're trying to prevent is someone stealing your certificate's private key.

  • Firstly, you may find you still need a way to revoke C_K_d, should its private key be compromised too. You don't necessarily gain that much using a scheme like you describe.
  • Secondly, "[...] stored in a special mass storage" sounds like you have access to the hardware and could potentially plug something in. Instead of twisting TLS like you're suggesting, I'd suggest using a Hardware Security Module: there are cryptographic tokens/smart cards from which the private key cannot be extracted, it can only be used on-board. You might have to leave the PIN code in clear in your server configuration, but at least the private key will never be copied, so if you suspect foul play, just unplug the device. (I've managed to run a Java-based SSL/TLS server using such a token and a PKCS#11 provider in the past. I'm not sure how this can be configured with other servers, but this is possible in principle.)

EDIT:

Just a bit of background about how SSL/TLS is used. There are essentially 3 categories of specifications involved:

  • SSL/TLS itself. Depending on the version this will be RFC 2246, 4346 or 5246. This describes how the protocol itself works (including the handshake). You could include in this category other RFCs that define additional cipher suites (e.g. Kerberos or EC).
  • Certificate validation/verification. Assuming X.509 certificates are used (as it is the case for HTTPS communications, see RFC 2818), clients rely on RFC 3280/5280. This defines how the client evaluates whether it considers a certificate genuine, trusted and valid for this purpose.
  • Host name verification. RFC 2818 Section 3.1 or RFC 6125: this defines how the client should decide whether the server certificate matches what the client was looking for.

As I was saying above, I don't think what you're trying to do can be done out of the box with these specifications.

It's not quite clear to me whether you're more after modifications involving the TLS Server Key Exchange message (so tweaking TLS itself) or new certificates (more along the lines of tweaking the certificate validation/verification step). It's easier to do the latter (both in theory and in practice), although both can be risky.

Since it seems that the problem you're trying to fix is the theft of your server private key, you may be interested in RFC 3820 (not to be confused with RFC 3280), which defines proxy certificates. Essentially, you can use an End-Entity Certificate (that is not a CA certificate) to issue a proxy certificate, usually with a much shorter validity period (e.g. 24 hours). This tends to be used in the Grid world to delegate authentication credentials, when connecting as a client. This aims to address the problem of potentially vulnerable private keys (on the machines where you delegate your credentials). I've never tried it from a server point of view, but it could work in principle. Apart from the generation of this proxy certificate, this approach wouldn't require many changes on the server side (they're X.509 certificates with a few specific attributes). However, this would still require changes on the client side to trust these certificates, since it would break RFC 3280/5280. (You can make modern versions of OpenSSL recognise such certificates.) This wouldn't work with most browsers out of the box.

At least, proxy certificates have a time limit. It's not clear how other schemes that you may be suggesting would help against the theft of private key. If you don't have a mechanism to revoke your temporary key/cert, the vulnerability would still exist, since a spoof server having one of your temporary private key could still impersonate your real server forever.

Considering the threat you seem to be worried about, a HSM still sounds like the best option, and it would work with existing stacks without tweaking the standards normally used.

Community
  • 1
Bruno
  • 10,765
  • 1
  • 39
  • 59
  • Proxy certificates: I never heard of them, and they might be what I am looking for, so I will consult the links you gave. Thank you for your time and explanations anyway. – curiousguy Jun 20 '12 at 07:58
  • @curiousguy, proxy certificates will not work out of the box with browsers at all. When you say above "*The only way seems a short-lived key*": again, it's not, a better protection against the attacks you have in mind is to use an HSM and make the private key read-only. – Bruno Jun 20 '12 at 10:05
  • "_proxy certificates will not work out of the box with browsers at all._" at least the concept is interesting... "_again, it's not, a better protection against the attacks you have in mind is to use an HSM_" if you have one – curiousguy Jun 20 '12 at 13:51
  • I thought HSM was a viable option since you were talking about extra hardware (including TPM). Depending on your budget, [here](http://www.startssl.com/?app=6) is an example that might not be too expensive. I've managed to run a Java web-server on a Linux box using the OpenSC PKCS#11 provider with an Aladdin eToken Pro 32K USB in the past. There are other models you could investigate. It's by far more viable than expecting every client browser to be compiled to support proxy certificates (unless you're in a very limited environment). – Bruno Jun 20 '12 at 14:19
  • "_I thought HSM was a viable option since you were talking about extra hardware (including TPM)._" In my question the use of specific hardware was just *an example of a configuration* where my proposed intermediate key might be beneficial for increased security. According to what you say, the only way to truly increase server secret key security is a specialised security token, so I will investigate that. – curiousguy Jun 20 '12 at 16:09
  • Ephemeral RSA keys were used back in the days of SSL 3.0 and TLS 1.0 for "export" cipher suites: the server key was RSA-1024 but signature-only; the key exchange was then done with a 512-bit ephemeral RSA key. This was for people who support only RSA, and not Diffie-Hellman. Need for that disappeared when the DH/RSA patents expired and the US export regulations changed, circa 2000. Export cipher suites have been removed from TLS 1.2. – Thomas Pornin Jan 04 '13 at 18:34