Digital Signatures
|
Digital Signatures
|
|
|
Digital signaturesDigital certificates are electronic files that act like a kind of online passport. They are issued by a trusted third party, a certificate authority (CA), which verifies the identity of the certificate's holder. They are tamper-proof and cannot be forged. Digital certificates do two things: They authenticate that their holders - people, web sites, and even network resources such as routers - are truly who or what they claim to be. They protect data exchanged online from theft or tampering. A major benefit of public key cryptography is that it provides a method for employing digital signatures. Digital signatures enable the recipient of information to verify the authenticity of the information's origin, and also verify that the information is intact. Thus, public key digital signatures provide authentication and data integrity. A digital signature also provides non-repudiation, which means that it prevents the sender from claiming that he or she did not actually send the information. These features are every bit as fundamental to cryptography as privacy, if not more.A digital signature serves the same purpose as a handwritten signature. However, a handwritten signature is easy to counterfeit. A digital signature is superior to a handwritten signature in that it is nearly impossible to counterfeit, plus it attests to the contents of the information as well as to the identity of the signer. Some people tend to use signatures more than they use encryption. For example, you may not care if anyone knows that you just deposited Rs 1000 in your account, but you do want to be sure it was the bank teller you were dealing with. The basic manner in which digital signatures are created is illustrated in Figure. Instead of encrypting information using someone else's public key, you encrypt it with your private key. If the information can be decrypted with your public key, then it must have originated with you.
 Figure 1-6. Simple digital signatures
Hash functionsThe system described above has some problems. It is slow, and it produces an enormous volume of data — at least double the size of the original information. An improvement on the above scheme is the addition of a one-way hash function in the process. A one-way hash function takes variable-length input — in this case, a message of any length, even thousands or millions of bits — and produces a fixed-length output; say, 160-bits. The hash function ensures that, if the information is changed in any way — even by just one bit — an entirely different output value is produced.PGP uses a cryptographically strong hash function on the plaintext the user is signing. This generates a fixed-length data item known as a message digest. (Again, any change to the information results in a totally different digest.) Then PGP uses the digest and the private key to create the "signature." PGP transmits the signature and the plaintext together. Upon receipt of the message, the recipient uses PGP to recompute the digest, thus verifying the signature. PGP can encrypt the plaintext or not; signing plaintext is useful if some of the recipients are not interested in or capable of verifying the signature. As long as a secure hash function is used, there is no way to take someone's signature from one document and attach it to another, or to alter a signed message in any way. The slightest change in a signed document will cause the digital signature verification process to fail.
 Figure 1-7. Secure digital signatures Digital signatures play a major role in authenticating and
validating other PGP users' keys.
Digital certificatesOne issue with public key cryptosystems is that users must be constantly vigilant to ensure that they are encrypting to the correct person's key. In an environment where it is safe to freely exchange keys via public servers, man-in-the-middle attacks are a potential threat. In this type of attack, someone posts a phony key with the name and user ID of the user's intended recipient. Data encrypted to — and intercepted by — the true owner of this bogus key is now in the wrong hands.In a public key environment, it is vital that you are assured that the public key to which you are encrypting data is in fact the public key of the intended recipient and not a forgery. You could simply encrypt only to those keys which have been physically handed to you. But suppose you need to exchange information with people you have never met; how can you tell that you have the correct key? Digital certificates, or certs, simplify the task of establishing whether a public key truly belongs to the purported owner. A certificate is a form of credential. Examples might be your driver's license, your social security card, or your birth certificate. Each of these has some information on it identifying you and some authorization stating that someone else has confirmed your identity. Some certificates, such as your passport, are important enough confirmation of your identity that you would not want to lose them, lest someone use them to impersonate you. A digital certificate is data that functions much like a physical certificate. A digital certificate is information included with a person's public key that helps others verify that a key is genuine or valid. Digital certificates are used to thwart attempts to substitute one person's key for another. A digital certificate consists of three things:
Thus, a certificate is basically a public key with one or two forms of ID attached, plus a hearty stamp of approval from some other trusted individual.
 Figure 1-8. Anatomy of a PGP certificate
Certificate distributionCertificates are utilized when it's necessary to exchange public keys with someone else. For small groups of people who wish to communicate securely, it is easy to manually exchange diskettes or emails containing each owner's public key. This is manual public key distribution, anditispracticalonlytoa certain point. Beyond that point, it is necessary to put systems into place that can provide the necessary security, storage, and exchange mechanisms so coworkers, business partners, or strangers could communicate if need be. These can come in the form of storage-only repositories called Certificate Servers, or more structured systems that provide additional key management features and are called Public Key Infrastructures (PKIs).Certificate servers Public Key Infrastructures
Certificate formatsA digital certificate is basically a collection of identifying information bound together with a public key and signed by a trusted third party to prove its authenticity. A digital certificate can be one of a number of different formats.PGP recognizes two different certificate formats:
PGP certificate format
One unique aspect of the PGP certificate format is that a single certificate can contain multiple signatures. Several or many people may sign the key/ identification pair to attest to their own assurance that the public key definitely belongs to the specified owner. If you look on a public certificate server, you may notice that certain certificates, such as that of PGP's creator, Phil Zimmermann, contain many signatures. Some PGP certificates consist of a public key with several labels, each of which contains a different means of identifying the key's owner (for example, the owner's name and corporate email account, the owner's nickname and home email account, a photograph of the owner — all in one certificate). The list of signatures of each of those identities may differ; signatures attest to the authenticity that one of the labels belongs to the public key, not that all the labels on the key are authentic. (Note that 'authentic' is in the eye of its beholder — signatures are opinions, and different people devote different levels of due diligence in checking authenticity before signing a key.)
 Figure 1-9. A PGP certificate X.509 certificate format Acertificate requires someone to validate that a public key and the name of the key's owner go together. With PGP certificates, anyone can play the role of validator. With X.509 certificates, the validator is always a Certification Authority or someone designated by a CA. (Bear in mind that PGP certificates also fully support a hierarchical structure using a CA to validate certificates.) An X.509 certificate is a collection of a standard set of fields containing information about a user or device and their corresponding public key. The X.509 standard defines what information goes into the certificate, and describes how to encode it (the data format). All X.509 certificates have the following data:
You might think of an X.509 certificate as looking like a standard paper certificate (similar to one you might have received for completing a class in basic First Aid) with a public key taped to it. It has your name and some information about you on it, plus the signature of the person who issued it to you.
 Figure 1-10. An X.509 certificate Probably the most widely visible use of X.509 certificates today is in
web browsers.
Validity and trustEvery user in a public key system is vulnerable to mistaking a phony key (certificate) for a real one. Validity is confidence that a public key certificate belongs to its purported owner. Validity is essential in a public key environment where you must constantly establish whether or not a particular certificate is authentic.When you've assured yourself that a certificate belonging to someone else is valid, you can sign the copy on your keyring to attest to the fact that you've checked the certificate and that it's an authentic one. If you want others to know that you gave the certificate your stamp of approval, you can export the signatureto a certificateserver so that others canseeit. As described in the section Public Key Infrastructures, some companies designate one or more Certification Authorities (CAs) to indicate certificate validity. In an organization using a PKI with X.509 certificates, it is the job of the CA to issue certificates to users — a process which generally entails responding to a user's request for a certificate. In an organization using PGP certificates without a PKI, it is the job of the CA to check the authenticity of all PGP certificates and then sign the good ones. Basically, the main purpose of a CA is to bind a public key to the identification information contained in the certificate and thus assure third parties that some measure of care was taken to ensure that this binding of the identification information and key is valid. The CA is the Grand Pooh-bah of validation in an organization; someone
whom everyone trusts, and in some organizations, like those using a PKI,
no certificate is considered valid unless it has been signed by a trusted
CA.
Checking validityOne way to establish validity is to go through some manual process. There are several ways to accomplish this. You could require your intended recipient to physically hand you a copy of his or her public key. But this is often inconvenient and inefficient.Another way is to manually check the certificate's fingerprint. Just as every human's fingerprints are unique, every PGP certificate's fingerprint is unique. The fingerprint is a hash of the user's certificate and appears as one of the certificate's properties. In PGP, the fingerprint can appear as a hexadecimal number or a series of so-called biometric words, which are phonetically distinct and are used to make the fingerprint identification process a little easier. You can check that a certificate is valid by calling the key's owner (so that you originate the transaction) and asking the owner to read his or her key's fingerprint to you and verifying that fingerprint against the one you believe to be the real one. This works if you know the owner's voice, but, how do you manually verify the identity of someone you don't know? Some people put the fingerprint of their key on their business cards for this very reason. Another way to establish validity of someone's certificate is to trust that a third individual has gone through the process of validating it. A CA, for example, is responsible for ensuring that prior to issuing to a certificate, he or she carefully checks it to be sure the public key portion really belongs to the purported owner. Anyone who trusts the CA will automatically consider any certificates signed by the CA to be valid. Another aspect of checking validity is to ensure that the certificate
has not been revoked. For more information, see the section Certificate Revocation.
Establishing trustYou validate certificates. You trust people. More specifically, you trust people to validate other people' certificates. Typically, unless the owner hands you the certificate, you have to go by someone else's word that it is valid.Meta and trusted introducers A CA can also be a meta-introducer. A meta-introducer bestows not only validity on keys, but bestows the ability to trust keys upon others. Similar to the king who hands his seal to his trusted advisors so they can act on his authority, the meta-introducer enables others to act as trusted introducers. These trusted introducers can validate keys to the same effect as that of the meta-introducer. They cannot, however, create new trusted introducers. Meta-introducer and trusted introducer are PGP terms. In an X.509 environment, the meta-introducer is called the root Certification Authority (root CA) and trusted introducers subordinate Certification Authorities. The root CA uses the private key associated with a special certificate
type called a root CA certificate to sign certificates. Any
certificate signed by the root CA certificate is viewed as valid by any
other certificate signed by the root. This validation process works even
for certificates signed by other CAs in the system — as long as the root
CA certificate signed the subordinate CA's certificate, any certificate
signed by the CAis considered valid to others within the hierarchy. This
process of checking back up through the systemto see who signed whose
certificate is called tracing a certification path or
certification chain.
Trust modelsIn relatively closed systems, such as within a small company, it is easy to trace a certification path back to the root CA. However, users must often communicate with people outside of their corporate environment, including some whom they have never met, such as vendors, customers, clients, associates, and so on. Establishing a line of trust to those who have not been explicitly trusted by your CA is difficult.Companies followone or another trust model, which dictates how
users will go about establishing certificate validity. There are three
different models:
Direct trust is the simplest trust model. In this model, a user trusts that a key is valid because he or she knows where it came from. All cryptosystems use this form of trust in some way. For example, in web browsers, the root Certification Authority keys are directly trusted because they were shipped by the manufacturer. If there is any form of hierarchy, it extends from these directly trusted certificates. In PGP, a user who validates keys herself and never sets another certificate to be a trusted introducer is using direct trust.
 Figure 1-11. Direct trust Hierarchical Trust
 Figure 1-12. Hierarchical trust Web of Trust Perhaps you've heard of the term six degrees of separation, which suggests that any person in the world can determine some link to any other person in the world using six or fewer other people as intermediaries. This is a web of introducers. It is also the PGP view of trust. PGP uses digital signatures as its form of introduction. When any user signs another's key, he or she becomes an introducer of that key. As this process goes on, it establishes a web of trust. In a PGP environment, any user can act as a certifying authority. Any PGP user can validate another PGP user's public key certificate. However, such a certificate is only valid to another user if the relying party recognizes the validator as a trusted introducer. (That is, you trust my opinion that others' keys are valid only if you consider me to be a trusted introducer. Otherwise, my opinion on other keys' validity is moot.) Stored on each user's public keyring are indicators of
Levels of trust in PGP There are three levels of trust you can assign to someone else's public key:
For example, suppose your key ring contains Alice's key. You have validated Alice's key and you indicate this by signing it. You know that Alice is a real stickler for validating others' keys. You therefore assign her key with Complete trust. This makes Alice a Certification Authority. If Alice signs another's key, it appears as Valid on your keyring. PGP requires one Completely trusted signature or two Marginally trusted
signatures to establish a key as valid. PGP's method of considering two
Marginals equal to one Complete is similar to a merchant asking for two
forms of ID. You might consider Alice fairly trustworthy and also consider
Bob fairly trustworthy. Either one alone runs the risk of accidentally
signing a counterfeit key, so you might not place complete trust in either
one. However, the odds that both individuals signed the same phony key are
probably small.
Certificate RevocationCertificates are only useful while they are valid. It is unsafe to simply assume that a certificate is valid forever. In most organizations and in all PKIs, certificates have a restricted lifetime. This constrains the period in which a system is vulnerable should a certificate compromise occur.Certificates are thus created with a scheduled validity period: a start date/time and an expiration date/ time. The certificate is expected to be usable for its entire validity period (its lifetime). When the certificate expires, it will no longer be valid, as the authenticity of its key/ identification pair are no longer assured. (The certificate can still be safely used to reconfirm information that was encrypted or signed within the validity period — it should not be trusted for cryptographic tasks moving forward, however.) There are also situations where it is necessary to invalidate a certificate prior to its expiration date, such as when an the certificate holder terminates employment with the company or suspects that the certificate's corresponding private key has been compromised. This is called revocation. Arevoked certificate is much more suspect than an expired certificate. Expired certificates are unusable, but do not carry the same threat of compromise as a revoked certificate. Anyone who has signed a certificate can revoke his or her signature on the certificate (provided he or she uses the same private key that created the signature). Arevoked signature indicates that the signer no longer believes the public key and identification information belong together, or that the certificate's public key (or corresponding private key) has been compromised. A revoked signature should carry nearly as much weight as a revoked certificate. With X.509 certificates, a revoked signature is practically the same as a revoked certificate given that the only signature on the certificate is the one that made it valid in the first place — the signature of the CA. PGP certificates provide the added feature that you can revoke your entire certificate (not just the signatures on it) if you yourself feel that the certificate has been compromised. Only the certificate's owner (the holder of its corresponding private
key) or someone whom the certificate's owner has designated as a
revoker can revoke a PGP certificate. (Designating a revoker is a useful
practice, as it's often the loss of the passphrase for the certificate's
corresponding private key that leads a PGP user to revoke his or her
certificate — a task that is only possible if one has access to the
private key.) Only the certificate's issuer can revoke an X.509
certificate.
Communicating that a certificate has been revokedWhen a certificate is revoked, it is important to make potential users of the certificate aware that it is no longer valid. With PGP certificates, the most common way to communicate that a certificate has been revoked is to post it on a certificate server so others who may wish to communicate with you are warned not to use that public key.In a PKI environment, communication of revoked certificates is most commonly achieved via a data structure called a Certificate Revocation List, or CRL, which is published by the CA. The CRL contains a time-stamped, validated list of all revoked, unexpired certificates in the system. Revoked certificates remain on the list only until they expire, then they are removed from the list — this keeps the list from getting too long. The CA distributes the CRL to users at some regularly scheduled
interval (and potentially off-cycle, whenever a certificate is revoked).
Theoretically, this will prevent users from unwittingly using a
compromised certificate. It is possible, though, that there may be a time
period between CRLs in which a newly compromised certificate is used.
|