Discussion:
How does X.509 really work?
(too old to reply)
Nimmi Srivastav
2009-04-03 03:10:14 UTC
Permalink
Hi,

First of all my apologies if this posting is OT. I am trying to
figure out how X.509 really works. I am surprised how difficult of a
time I am having reaching a website that explains this whole stuff in
layman terms. I now understand how digital signatures work, thanks to
the following website:

http://www.x500standard.com/index.php?n=X509.X509Overview

[
Sending side

* A message digest is generated using some hashing algorithm.
* Using the private key, the message digest is encrypted to create
the signature.
* The digital signature is appended the message.
* The identification of the signing algorithm, that is the
combination of the hashing algorithm and the encryption algorithm, is
also attached (The signing algorithm is identified by an ASN.1 object
identifier)

Receiving side
* The signature is decrypted using the public key to restore the
message digest as generated by the sender
* A local message digest of the message is generated.
* The two message digests are compared for equality.
]

Unfortunately this website does not describe X.509 [It simply says
"More to come (hopefully)"]. Then I thought let me extrapolate what I
learned above to try to figure out how X.509 really works. This is
what I have guessed. I am sure my guess is wrong and I would
appreciate if you can correct me.

The Certification Authority (CA) checks data about the certified
entity. After satisfying itself about the identity of the certified
entity, it hashes the certified entity's data, along with data about
itself, and encrypts the resulting digest with its private key. This
is the digital signature of the CA, which is part of the X.509
certificate. The X.509 certificate is then sent to the certified
entity.

When the certified entity has to send some data out, it first
generates a digest from the data and then encrypts the digest using
its private key to create the signature, which is appended to the
data. Then the certified entity sends out the data along with the
certificate.

On the receiving side, first the CAs digital signature in the X.509
certificate is decrypted, using the CA's public key to restore
information about the certified entity. (If what I say is right, is
the public key part of the certificate, or does the receiving end know
the public key of well known CAs?). A local digest of this
information is generated using the same algorithm that is indicated in
the CA's digital signature. If the two are the same, then you know
the certificate is valid.

After establishing that the certificate is valid, you check if the
message has been proprely signed, as described above (decrypting with
public keys, locally generating the digest and comparing the decrypted
and locally generated digests).

Now the question arises if Alice uses Bob's X.509 certificate, how can
Charles detect that? Charles can tell that this is a valid X.509
certificate from a well known CA, but how can he be sure that only
Bob, and not Alice, is using the certificate. This is where my
understanding falls apart and where I need your help.

Thanks
NS
r***@yahoo.com
2009-04-03 03:57:08 UTC
Permalink
Post by Nimmi Srivastav
Now the question arises if Alice uses Bob's X.509 certificate, how can
Charles detect that?  Charles can tell that this is a valid X.509
certificate from a well known CA, but how can he be sure that only
Bob, and not Alice, is using the certificate.  This is where my
understanding falls apart and where I need your help.
Unless I'm not understanding the question...

Alice cannot use Bob's cert, since only Bob knows the private key (the
CA is publishing his public key). If Alice *knows* Bob's secret key,
she can impersonate him to whatever extent she desires, so long as she
can also subvert whatever is being used to identify the cert (the x.
500 Distinguished Name or, more commonly, an Alternate Name, like a
web site's DNS name) - note that we usually assume that meeting the
latter condition is fairly easy for Alice.

IOW, what validating the cert for some web site does is it guarantees
that the web site you're communicating with knows the private key
associated with the cert stored for that web site by the CA you're
trusting.

If Bob looses control of his cert (private key), he'll call the CA and
have it revoked. Note that some browsers do not do all that good a
job of checking for revocations, but at least no new users will get
the old cert (assuming a semi-competent CA), and everyone else should
drop off sooner or later once the browsers decide to actually
revalidate the cert for the website.
Paul Rubin
2009-04-03 07:15:29 UTC
Permalink
Post by Nimmi Srivastav
Now the question arises if Alice uses Bob's X.509 certificate, how can
Charles detect that?
Bob's certificate contain's Bob's public key, and the protocol (TLS or
whatever) requires Bob to demonstrate possession of the private key
that matches the public key. Alice (presmably) doesn't have the
private key, so can't carry out the protocol. Of course if Alice can
compromise Bob's private key, she can impersonate Bob. Bob has to
be careful about computer security to prevent that from happening.
Loading...