8

All things being equal; suppose I have a CA chain that has 1024 bits of RSA encryption. Does this mean that my selection of a child CA or WebServer certificate gains no benefit from a higher level of encryption?

My theory in that question is that it if it takes an attacker N compute cycles to attack a certificate with 1024 bits of encryption, then they might as well attack the highest one in the chain.

What if the expiration dates of the parent (1024 bit) certificates were 1 year, and the expiration of my stronger (4028 bit) certificate expires in 2 years (or longer). Is that technically possible? Is it beneficial? If so, in what way?

AviD
  • 72,708
  • 22
  • 137
  • 218
makerofthings7
  • 50,488
  • 54
  • 253
  • 542
  • 1
    It does not matter: somebody will compromise your clients' computers, or your Web servers, or your databases, or both, before/instead of breaking the 1024 bits RSA key! – corrector Sep 21 '11 at 00:49

6 Answers6

11

Short answer: Yes, there is some potential benefit for end-entities to choose a public key that is larger than the CA's public key.

The question is not entirely clear, but I presume your situation is that the root or parent uses a 1024-bit RSA key (i.e., the end-entity's cert is signed with a 1024-bit RSA key), and the end-entity uses a 2048-bit RSA key (i.e., the public key being certified and used by the end host is a 2048-bit RSA key).

In this situation, I can see two potential security benefits to using a 2048-bit end-entity cert instead of a 1024-bit end-entity cert:

  • You are safe against an attacker who can break 1024-bit RSA, but cannot break 2048-bit RSA, and can only eavesdrop but cannot (or is not willing to) actively tamper with connections. In comparison, if you used a 1024-bit RSA key, then such an attacker could recover your RSA private key, eavesdrop on connections, and decrypt the encrypted traffic.

  • You are safe against an attacker who, five years from now, breaks 1024-bit RSA but cannot break 2048-bit RSA, assuming that the CA transition to 2048-bit RSA within the next few years (as many CAs are doing and many browsers are requiring). This is because an attacker who is able to recover the CA's 1024-bit signing key five years from now does not gain anything by doing so, if that key is no longer valid. The CA's signing key doesn't help the attacker decrypt any SSL-encrypted traffic he may have access to (not even old traffic he recorded long ago). The only thing an attacker can do with a CA's signing key is sign a new bogus certificate and use it to mount a man-in-the-middle attack on users, but if the CA's root cert and 1024-bit public key is no longer accepted by browsers five years from now, that doesn't help the attacker at all: he's too late.

[In addition, there may be some key management benefits to choosing a 2048-bit key now and being able to continue using it for several years, even if you have to renew your cert to do so, as opposed to having to change keys in a year or two. To be clear, this is not a security benefit; it is merely a potential logistical benefit, depending upon how annoying you find it to have to change your keys at some point in the future.]

Bottom line: There might be some benefit to choosing an end-entity key that is larger than the CA's key. However, I don't want to claim the benefit is overwhelming, or that the size of the end-entity public key is all that matters. Against a powerful attacker who is able and willing to mount active attacks, and who can break 1024-bit RSA within the lifetime of validity of the CA's root cert, you're probably hosed no matter what size public key you choose.

D.W.
  • 98,860
  • 33
  • 271
  • 588
10

Seems like you are asking 2 questions:

Is there any benefit to having the end entity certificate have a larger key space than the CAs in the signing chain

I agree with other posters that the result is mixed - but I want to break it down into the typical security features:

  • Confidentiality - if you are using the end entity key pair for confidentiality (key encryption during SSL setup, encryption of data for storage or transmission) - then you are getting the benefit of the larger key regardless of what the CA signer is doing. Breaking your encryption is entirely related to finding your private key (or finding a weakness in algorithm)
  • Integrity - if you are using the end entity key pair for signing data, then cracking your signature is linked to the strength of you key. However, integrity checks are often combined with authentication checks - see below.

  • Authentication - here's the rub. Your authentication/non-repudiation abilities become diminished if your CA's private key is easier to guess. If I can find your CA's private key due to the smaller key space, then I can pretend to be your CA and I can make a certificate and key pair of any size that looks like you and has a key pair that I control. That pretty much shoots authentication in the foot. It won't be caught by a list of trusted CA certs because the attacker will emulating one of those configured, trusted certs. And it will be hard to detect until after the break in is found. Also, revoking a CA is painful. Either you should have a certificate status check in place in every consuming system that checks the status of both the end entity and the CA chain, or you must revoke every valid end entity that was issued by the CA. This gets even harder if we are talking about a small key space in a self-signed root certificate. There is no way to status check the root. The CA system would have to issue a huge public warning and have any relying party remove the root and all it's sub CAs from their trusted stores.

  • Availability - when I think about availability in PKI, I think about use of PKI for authentication/access control to make the services available only to the privileged users. In that light, availability is shot just as much as authentication.

So, the summary - what are you using the certificate for? If you are only using it for confidentiality and pure integrity - you're not so badly off. But keep in mind the frequently, PKI protection mechanisms mix these categories. SSL client or server auth is both a way to set up a secure channel (confidentiality) and a way to vet the identity of the server (authentication). Email signatures are both a way to tamper proof the transmission (integrity) and a proof that the transmission came from the sender (authentication). It gets hairy awfully quickly.

Next question...

Is it beneficial or even possible to have my end entity be of a longer validity than the CA that issued it?

In the PKI systems I've worked on - no absolutely not - end entity certificates cannot be issued as a longer validity period than the life of the CA certificate.

Stepping back from actual experience, however, I'm looking at the RFC for X509 Certificates: http://www.ietf.org/rfc/rfc3280.txt

Section 6.1.3  Basic Certificate Processing

includes the verification of validity dates for each certificate in the chain.

This section is part of:

6.1  Basic Path Validation

   This text describes an algorithm for X.509 path processing.  A
   conformant implementation MUST include an X.509 path processing
   procedure that is functionally equivalent to the external behavior of
   this algorithm.  However, support for some of the certificate
   extensions processed in this algorithm are OPTIONAL for compliant
   implementations.  Clients that do not support these extensions MAY
   omit the corresponding steps in the path validation algorithm.

So it should be done for every certificate in the path (ie, the end entity, every signing CA and the Root)

Validity checks are not an OPTIONAL extension, they are required part of the certificate.

IF the system is doing path validation correctly, having a longer validity on end entity certificate should do you no good. I didn't look farther to see if it's allowed. I believe the CA systems I've tested have had a setting that disallowed this, but I also think that with some degree of creativity I may have been able to generate a cert that broke this mould. Keep in mind, however, I was doing that with sys admin privilege and possibly even white box testing mechanisms that shouldn't be available in a hardened CA. I was also doing that 10+ years ago with CAs that are no longer the market today - mileage may vary.

Ulkoma
  • 8,793
  • 16
  • 66
  • 95
bethlakshmi
  • 11,656
  • 1
  • 28
  • 59
  • Yes, it is possible with Positive SSL's CA. I have a working sample of a 4096 bit cert with 2048 bits upstream. See for yourself at https://www.agent7.net – makerofthings7 Mar 16 '11 at 22:12
  • @mkerofthings - yes, I see that... although when I was conjecturing about CAs did or did not allow, I was talking about validity date, not key size. Although I see that you Root cert will expire before your CA cert... so you're actually doing both strange things. – bethlakshmi Mar 17 '11 at 14:21
4

There are two kinds of attack that an attacker may try to mount:

  • Active attack: the attacker meddles with the data packets at the time you connect to the server (possibly up to running his own complete fake server). To do that, the attacker must be able to break one of the public keys right now (the server's key or the key of one of the CA).

  • Passive attack: the attacker records the data packets, but does not alter them. Afterwards, the attacker tries to break whatever key was used for encryption, to unravel the plaintext data. In the case of SSL/TLS with one of the "RSA" cipher suites (not the "DHE_RSA" suites), breaking the server's RSA public key is sufficient to decrypt the whole session.

The important point is that breaking the key of a CA afterwards gives no advantage whatsoever to the attacker (it helps him only for attacking sessions which occur after the breakage). However, breaking the server's key itself may help him decrypting previously recorded sessions. Therefore, the security constraints on the server's key are actually stricter than for CA key; it thus makes sense to use a bigger key for the server itself.

(The "DHE" cipher suites use the server's key for a signature only, which transfers the issue to the ephemeral Diffie-Hellman key which the server decides to use for the actual key exchange. There again, the server is logically entitled to use a DH key that is stronger than its own RSA key or the CA keys.)

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
2

If an attacker wishes to impersonate your site, they can do this by either trying to break your end-entity key, or they can break one of the signing CA keys, which would allow them to issue their own end-entity certs for any domain including yours. Against this attack, the cert chain is as strong as its weakest link.

If an attacker wishes to read SSL-encrypted traffic from your site, the attacker must compromise the end-entity key; compromising a CA key does not help here. If you are concerned about this attack, it might make sense to have a longer end-entity key. Also keep in mind that this particular attack can be prevented by the use of ephemeral DH ciphersuites, with some cost in performance.

As for having an end-entity cert with a longer validity period than a signing certificate, there are several possible issues there. First, a CA might not even agree to issue such a cert; it may truncate the validity period to that of its root cert. Second, even if you got such a cert issued, the chain would fail to verify as soon as the earliest cert in the chain expired. There may be an exception to this in the case of a cert signed directly by a trusted root.

Tom Wu
  • 309
  • 1
  • 1
  • pretty good answer, but the second paragraph isn't quite right. An active attacker who compromises the CA key but not the end-entity key can still read SSL-encrypted traffic by mounting an (active) man-in-the-middle attack (involving a forged cert). This does require the attacker to have the ability to hijack traffic (e.g., through DNS hijacking, ARP spoofing, etc.) and to be willing to engage in an active attack. – D.W. Mar 18 '11 at 16:57
  • Yes, but I covered that case in the first paragraph; obviously an impersonator has the option of proxying traffic and acting as a man-in-the-middle. The "read traffic" attack covers instances of passive eavesdropping; in particular, cases where the attacker captures traffic passively and breaks the key later, revealing past cleartext. This attack cannot be mounted if the attacker compromises a signing CA key. This is a very different threat and a clear case where having a stronger end-entity key than signing CA key might make sense. – Tom Wu Mar 18 '11 at 22:35
  • all I'm saying is that the 1st sentence and 3rd of the 2nd paragraph are not accurate, and hence have a significant potential to mislead readers. I suspect the "read traffic" distinction is not necessarily obvious to the average reader. I know that *you* know all this extremely well, but revising your second paragraph might help readers understand it better. In other words, I'm not criticizing your knowledge, I'm suggesting a way to make this clearer and more helpful to readers. – D.W. Mar 19 '11 at 03:52
1

If the website key length is the same as the CA key, then the attacker may attack the website key since there is more value to be gained with the same effort. The reason is that all previously (and future) data encrypted data may be decrypted. This also allows for MITM attacks.

However if the website key is larger than the CA key, then the attacker is more likely to just attack the CA key, and in that case only MITM attacks are possible. All data previously encrypted with the website key is still safe. All future data may be vulnerable to MITM attacks.

makerofthings7
  • 50,488
  • 54
  • 253
  • 542
0

  1. CA only validates your certificate, It has nothing to do with your secure connection with your client, So your extra bit-length would benefit your connection. If an attacker breaks into your CA, he can only attempt MITM's on your clients and not break your cipher.

  2. Yes it is possible. CA would renew his certificate asap.

AbiusX
  • 132
  • 3