Trusting and Certificates

A shortcoming of the direct signature scheme lies in the impossibility to guarantee that the association key-user is genuine, i.e., that a public key actually comes from the person or organization to which it is claimed to belong, so that malicious users could exploit false identities or pretend to be someone else. To make up for this lack, a widespread solution is represented by the introduction of digital certificates, i.e., electronic documents (files) that unambiguously identify signees. They are obtained by means of someone who guarantees the real association of a public key to a spe-cific user, unambiguously identified. In such a case, the digital envelope to be sent to the receiver must include three items (files): the document/message, its digital signature and the associated certificate.

A digital certificate typically reports the following information:

ID A serial number that uniquely identifies the certificate.

Authority The entity that verified the information and issued the certificate.

Validity The starting and expiration dates of the certification.

User The data identifying the entity to be certified (e.g., name, address, etc.).

Key The public key to be certified and its intended use (e.g., encryption, signature, certificate signing, etc.).

Signature Algorithm The algorithm used to create the signature.

Fingerprint The hash of the certificate, to ensure that it has not been forged, and the algorithm used to produce such a fingerprint.

Translated into natural language, a certificate means approximately “I hereby certify, under my responsibility, that its owner is actually who he claims to be”, and hence that the information it contains (and specifically the association between the reported identity data and public key) is valid. This claim is technically imple-mented in the issuer digitally signing the certificate, and consequently undertak-ing the responsibility of the certificate itself. A certificate is self-signed when it is signed/issued by the same entity that it certifies. Of course, the trust a certificate deserves is strictly related to the reliability of its issuer, which can be assessed ac-cording to two different strategies, that give rise to the following schemes:

Public Key Infrastructure (PKI) in which the signature belongs to a Trusted Third Party (TTP), often called a Certificate Authority (CA);

Web of Trust in which the certificate is either self-signed by the user or it is signed by other users that endorse its validity.

A PKI must declare the security policy it conforms to, the procedure it follows for emission, registration, suspension and revocation of certificates (Certificate Practice Statement, or CPS), its system of CAs, its system of Registration Authorities (RAs) for user registration and authentication, and its certificate server. A CA, in particular, is required to bring up all proper actions aimed at verifying the certified entities’

identity, in order to justify the trust that the users of their certificates place on them.

In case of problems, a CA can suspend or even completely withdraw a certificate, inserting it into a Certificate Suspension List (CSL) or into a Certificate Revocation List (CRL) accordingly. Then, the question of who guarantees for the issuer arises.

A possible solution is requiring the CA to exhibit a certificate issued by a higher-level CA in a hierarchy of increasingly important CAs. Users, typically exploiting suitable software, check that the private key used to sign a certificate matches the public key in the CA’s certificate. This does not completely solve the problem, but limits it to the highest CA only (root), which provides the ultimate assurance in each particular PKI organization. Obviously, there being nobody that guarantees for the root, its certificate (also called root certificate) can only be self-signed. It goes without saying that, if the root certificate is fake, the whole tree of CAs and certificates in the PKI becomes untrustable, and hence the procedure for issuing root certificates must be accomplished with extreme care in order to avoid any kind of bug or flaw.

In a Web of Trust scheme, the responsibility of guaranteeing a certificate is not charged on a single, formally trusted, entity, but it is shared among several entities that claim that certificate to be reliable. More specifically, each user produces a self-signed certificate that is subsequently additionally self-signed by other users that confirm its being reliable (i.e., that the identity and public key contained therein are genuine

and actually correspond). In this case, other users base their trust about that certifi-cate being correct on these additional signatures, qualitatively (they might trust—or untrust—specific users that signed that certificate, and as a consequence trust—or untrust—that certificate), or quantitatively (their confidence in the reliability of the certificate might increase with the number of additional signatures supporting it).

Also in this case the problem arises of who guarantees for the actual identity of the additional supporters. Some of them could be personally known to the user, and hence their public keys might have been passed directly to him. Otherwise, the user must take into account some degree of hazard in ‘propagating’ the trust from known persons to the persons they guarantee for. Some CAs also maintain a Web of Trust, counting and managing the endorsements to the subscribing certificates.

To ensure automatic processing by security-aware software applications, and in-teroperability between different CAs, certificates must be produced according to pre-defined standards. In particular, the current official standard, called X.509, is established by RFC 5280 [13], that also specifies regulations for CRLs, a useful means for identifying certificates that for some reason must not be trusted anymore.

Certificates are thoroughly exploited in the HTTPS (HTTP Secure) Internet en-vironment for Web sites, that enforces secure communication and data integrity on TCP/IP networks by underlying HTTP with encrypted source-destination commu-nication at the transport level using the Secure Socket Layer (SSL) protocol or, more recently, the Transport Layer Security (TLS) protocol. In this setting, each Web op-erator must obtain a certificate by applying to a CA, indicating the site name, con-tact email address, and company information. The usual check performed by the CA consists in verifying that the contact email address for the Web site specified in the certificate request corresponds to that supplied in the public domain name registrar. If the application is successful, the public certificate is issued by the CA.

It will be provided by the Web server hosting the site to the Web browsers of the users connecting to it, in order to prove that the site identification is reliable. The root certificates of some CAs that fulfill given management standards can be na-tively embedded in the Web browsers: in case they are, the browser will consider as trusted all the sites having certificates depending on those CAs; in case they are not, the root certificates will be considered as self-signed certificates. If the browser successfully checks the certificate, the connection can be established and the trans-action performed, while in the opposite case a warning message is displayed to the user, asking him to abort or confirm the connection under his own responsibility.

The system might not be completely safe due to the fact that three strictly related roles come into play, whose underlying actors could be different, and hence the rela-tionship among them could be deceived: the purchaser of the certificate, the Web site operator, and the author of the Web site content. Thus, strictly speaking, an HTTPS Web site is not ‘secure’ at all: the end user can only be sure that the registered email address corresponds to the certified one and that the site address itself is the original one, but it could be operated by someone different than the person that registered the domain name, or its content could have been hacked.