How to secure the transfer of public key to CA
stefan
certificate for you.
Isn't it a risk that someone will pick up System A's public key during
transmission to the CA and replace it with another?
Does System A have to encrypt his public key with the CA public key.
Happy for someone giving an explanation to how it should work in
practise when transmitting your public key to a CA.
Charlie Clayton
This is a tough one to answer in just a few sentences. I recommend you read
Understanding Public Key Infrastructure by Adams & Lloyd.
When you send your Public Key to the CA, it's normally over an SSL session.
What this means is that your Public Key is encrypted, but not with the CA's
key. It's encrypted with a symmetric key negotiated by the CA and your
system. The sender's Public Key can't just be replaced.
The certificate (signed and hashed Public Key, and a fw other things, too)
is then sent to the sender by email, so the bad guy would need to hijack the
email with the certificate coming from the CA. Once the bad guy gets the
certificate, he'll need to load it into his server, which I am presuming is
going to mimic the original sender's site. But it will fail because the
certificate will be for the wrong server name for which the certificate was
issued.
It's not impossible, but the resources necessary would not be worth the
effort. There are other matters of higher concern, of which I am not at
liberty to discuss. Suffice to say, I'm always looking to break the system,
as are many others. If you find a way, please let me know.
"stefan" <stefan...@combitechsystems.com> wrote in message
news:1db1c6a1.04091...@posting.google.com...
Wimbo
Hash: SHA1
stefan wrote:
> When System A have created a pair of keys he wants the CA to create a
> certificate for you.
> Isn't it a risk that someone will pick up System A's public key during
> transmission to the CA and replace it with another?
This is possible but very unlikely. Today most of the SSL certificates
are V3 now (Comodo still seems to issue some V1's at this moment). Which
means that the entire certificate chain gets verified and this way a man
in the middle attack is more difficult. The 'attacker' has to insert his
root CA into your certificate within your browser / OS. This means your
trying to do some secure stuff on a compromised machine......
> Does System A have to encrypt his public key with the CA public key.
If System A is compromised by a 'man-in-the-middle', than that's useless
as well, because your probably encrypting it to the certificate of the
'attacker'.
>
> Happy for someone giving an explanation to how it should work in
> practise when transmitting your public key to a CA.
Normal operation (Verisign):
Fill in a form with name, address, CC, password (aka challenge phrase)
etc. When submitting this information, a control is loaded in the
browser which triggers the creation of a public and private key.
The public key is transmitted to the CA (along with the other info).
A confirmation e-mail is send to the applicant. When the CC information
is correct the applicant receives an e-mail containing an URL,
Pickup-PIN etc.
With this information, and the password earlier created, the applicant
can collect the certificate. Another browser control makes sure that the
certificate is 'combined' with the private key in the certificate store.
The description above is for Class 1 certificates (person not
validated). Which means there is no real verification is the the person
is who he/she says he/she is. The only thing which is 'real' is the CC
(which might be stolen or whatever).
For class 2 and 3 certificates apply different rules for certificate
enrollment. The higher the class, the more they need to know from you
(passport etc.)
Summary: If you want to make sure that everything goes fine (with SSL);
- - Remove all trusted certificates from your browser (trust no one).
- - Verify all SSL certificates while you're browsing / buying or
whatever (validity, revocation and publisher).
- - Compare every SSL certificate serial, publisher etc. with info
available at the CA website (check the repository of the CA).
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1
iQA/AwUBQUhy8gIW7Y+ImIjiEQLK3ACbBXAvQnI70S+oxhEQoSZqFSggHvYAoLcb
Md/DkqrSfE1W3lsA5wKmT1Kp
=hOyY
-----END PGP SIGNATURE-----