|
|
|
|
| 11 Certificate inspection | Contents |
|
How do you know if a certificate actually belongs to the sender? And vice versa - why should the person you are writing to believe that the certificate you sent to him is really yours? The sender's name on an e-mail means nothing, just like putting a sender's name on an envelope.
If your bank, receives an e-mail with your name, with a request to transfer your entire bank balance to a numbered account in the Bahamas, we should hope that it will refuse to do so - no matter what the e-mail address is. On its own, an e-mail address itself does not really say anything about the sender's identity.
If you are only corresponding with a very small circle of people, it is easy to check their identity: You check the fingerprint of the other certificate.
Each certificate features a unique identification, which is even better than someone's fingerprint. For this reason this identification is also referred to as a "fingerprint".
If you display the details of a certificate in Kleopatra, e.g. by double-clicking on the certificate, you will see its 40-character fingerprint, among other things:
The fingerprint of the above OpenPGP certificate is therefore as
follows:
7EDC0D141A82250847448E91FE7EEC85C93D94BA
In short - the fingerprint clearly identifies the certificate and
its owner.
Simply call the person you are corresponding with and let them read the fingerprint of their certificate to you. If the information matches the certificate you have on hand, you clearly have the right certificate.
Of course you can also meet the owner of the certificate in person, or use another method to ensure that certificate and owner can be matched. Frequently, the fingerprint is also printed on business cards; therefore, if you have a business card whose authenticity is guaranteed, you can save yourself a phone call.
Once you have obtained confirmation of the authenticity of the certificate "via a fingerprint", you can authenticate it - but only in OpenPGP. With X.509, users cannot authenticate certificates - this can only be done by the certificate authorities (CA).
By authenticating a certificate, you are letting other (Gpg4win) users know that you are of the opinion that this certificate is real - hence authentic: You are acting as a kind of "godfather" for this certificate, and help to increase the general level of trust in its authenticity.
So how does the authentication process work?
In Kleopatra, select an OpenPGP certificate that you think is real and
would like to authenticate. In the menu, select:
Certificates -> Authenticate certificates...
Reconfirm the OpenPGP certificate to be authenticated in the following dialog, using [Next]:
In the next step, select your own OpenPGP certificate, which you will use to authenticate the certificate selected in the last step:
Here you decide whether to [Authenticate for private use only] or or [Authenticate and make visible to all]. With the last variant, you have the option of subsequently uploading the authenticated certificate to an OpenPGP certificate server, and hence make an updated and authenticated certificate available to the entire world.
Now confirm your selection with [Authenticate].
Similar to the process of signing an e-mail, you also have to enter your passphrase when authenticating a certificate (with your private key). The authentication proccess is only complete once this information is entered correctly.
Following a successful authentication, the following window appears:
Do you want to check the authentication one more? To do this, open
the certificate details of the certificate you have just
authenticated.Select the tab User ID and authentications and
click on the button [Obtain authentications].
You will now see all authentications contained in this certificate, sorted by user ID. You should also be able to see your certificate in this list, if you have just authenticated it.
The process of authenticating certificates creates a "Web of Trust" (WoT), which extends beyond the group of Gpg4win users and their correspondence, and it means that you are not always required to verify an OpenPGP certificate for its authenticity.
Naturally, trust in a certificate will increase if it has been authenticated by a lot of people. Your own OpenPGP certificate will receive authentications from other GnuPG users over time. This enables more and more people to trust that this certificate is really yours and not someone else's.
The continued weaving of this "Web of Trust" creates a flexible authentication structure.
There is one theoretical possibility of making this certificate test null and void: Someone plants a wrong certificate on you. In other words, you have a public OpenPGP key that pretends to be from X but in reality was replaced?? by Y. If this falsified certificate is authenticated, it clearly creates a problem for the "Web of Trust". For this reason it is very important to make sure that prior to authenticating a certifidate, you make absolutely sure the certificate really belongs to the person that purports to own it.
But what if a bank or government authority wants to check whether the certificates of their customers are real? Surely, they cannot call them all ...
In this case, we need a "superordinate" instance that all users can trust. After all, you do not personally check the ID of a person not known to you by phoning the municipal office, but rather trust that the office that issued the ID will have already checked and authenticated these details.
These types of authentication instances also exist in the case of OpenPGP certificates. In Germany, for example, the magazine c't has long been offering such a service free of charge, as have many universities.
Therefore, if you have received an OpenPGP certificate whose authenticity has been confirmed by such an authentication instance, you should be able to rely on it.
Such authentication instances or "Trust Centers" are also provided for in other encryption methods - such as S/MIME. However, in contrast to the "Web of Trust", these feature a hierarchical structure, with a "top authentication instance" that authenticates additional "sub-instances" and entitles them to authenticate user certificates (see Chapter 5).
The best way to describe this infrastructure is to use the example of a seal: The sticker on your license plate can only be provided by an institution that is authorised to issue such stickers, and they have received that right from another superordinate body. On a technical level, an authentication is nothing more than an authenticating party signing a certificate.
Of course, hierarchical authentication infrastructures are much better suited to the requirements of government and official instances than the loose "Web ofTrust" of GnuPG, which is based on mutual trust. At the same time, the key aspect of the authentication is the same for both: Gpg4win also supports a hierarchical authentication (S/MIME) in addition to the "Web of Trust" (OpenPGP). Accordingly, Gpg4win offers a basis that corresponds with the Signature Act of the Federal Republic of Germany.
If you would like to learn more about this topic, the following websites provide more information on this and other IT security topics:
Another, rather technical, information source on the issue of
authentication infrastructure is the GnuPG handbook, which can also be
found at:
www.gnupg.org/gph/en/manual.html
© 31. August 2010, v3.0.0-beta1 (last minor changes from 21. September 2010)
The Gpg4win Compendium is filed under the
GNU Free Documentation License v1.2.
|
|
|
|
| 11 Certificate inspection | Contents |
|