At the definition level, PKI is a sort of a distributed system of trust. All participants within the system trust another, third-party system. To make any sense of this, let's step back for a second and recall our Kerberos discussions earlier in the book.
We established that Kerberos is based on a symmetric cryptographic algorithms. We also established that any new service request involves a third party, the KDC. Both participants of a conversation trust the KDC explicitly. Every new service request involves a session setup, during which mutual authentication is performed. The KDC issues a session key by encrypting to "shared secret," something both the KDC and the party know (it is established when a party joins the domain, and is renewed periodically).
Each session established within Kerberos will use its unique session key. Session keys are unlikely security targets, since they are pretty useless in any other conversation. The problem is, how do we make sure that all parties engaging in a conversation obtain this ever-changing unique session key, securely? After all, we must transfer it via insecure network media.
Kerberos, being based on DES and AES symmetric cryptography, solves the problem of secure key exchange by using the preshared secret we just mentioned. That preshared secret is used to obtain a unique session key. That works quite well, where preshared secrets have been established well in advance of any secure communication taking place. It can only happen when initial setup of the preshared secret can be guaranteed to remain private and secure.
What if we wanted to engage in an encrypted communication between entities that do not have this preexisting relationship, because initial preshared key was impossible to set up securely, or where setting up such a relationship is not feasible due to scalability concerns? This problem is solved with PKI.
At a high level, a "key" is a mathematical formula, used to scramble and unscramble data. In symmetric crypto systems, the same key is used to both encrypt and decrypt the information. The key must be known to both parties engaging in a conversation, and it must be kept strictly confidential. The main advantage of this system is its relative simplicity, and higher cryptographic performance.
In asymmetric crypto systems, different keys (formulas) are used to encrypt and decrypt data. Encryption keys are "public" and are freely available to anyone who wishes to encrypt information and send it to the recipient. "Private" keys are known only to the recipient, and they are used to decrypt the information. They can only decrypt what was encrypted with the matching public key of the same key pair. The main advantage of this approach is its suitability to Internet applications, since no preexisting relationship is required. Parties do not need to exchange any supersensitive information before encrypted communication can take place (they do need to exchange public keys; in case of accessing a service, that happens automatically and without any risk of compromising security of the system).
PKI is an asymmetrical encryption system. It uses different keys to encrypt and decrypt information. It is aimed at solving the following three main challenges:
■ The need for strong encryption mechanisms with the ability to decrypt data. Encryption keys used to encrypt the information should be exchanged over the Internet or private network in an open form, but those who intercept this information should not be able to read intercepted, encrypted data (data confidentiality).
■ The need to guarantee data authenticity and ensure that communicating parties are indeed who they say they are. You need to be sure that the information received, say, through e-mail is coming from the user who sent it. This will guarantee the communicating party's identity, also guaranteeing that they won't be able to deny the fact that they sent the information (without first admitting that their private key was stolen or compromised). The same holds true for user-server communication: you need to be sure that you are sending information to the intended server, and not to a host impersonating this server (non-repudiation).
■ The message that was sent can be digitally signed. When intended recipient gets the message, he or she can perform an independent check, or "one-way hashing," of the entire message and compare it to the value in the digital signature. If values do not match, the message must have been tampered with in transit. This verification does not hide the actual text of the message, so it is not to be confused with encryption. However, it can be used to guarantee that the text of the message reached its intended recipient in its initial form (data integrity).
PKI solves all three issues. Public key cryptography is a fairly reliable method of transmitting data in a secure way, in principle. PKI found its way into Windows technologies and has been used in Microsoft products since the days of Windows NT 4.0.
Let's say HostA and HostB engage in a secure transaction and exchange their public keys using the Internet. HostA uses HostB's public key to encrypt the information, which is then sent to HostB for processing. If this information is intercepted, along with the public key, an attacker will not be able to read the content of the message. HostB then uses its "private" key that corresponds to the public key submitted to HostA to decrypt the information. There is a mathematical relation between public and private keys that belong to the same key pair, but when strong algorithms are used, knowing the public key is not enough to deduce the value of the private key. The only thing that an attacker would be able to do with the public key is encrypt his own messages for submission to HostB. This is why it is crucial to make sure no one else has your private key: if it leaks, integrity of the key pair is lost for good.
This takes care of the need for data confidentiality. Non-repudiation and data integrity problems are addressed through digital signing. It works the opposite way: instead of encrypting the information to a public key that belongs to HostB, HostA uses its own private key and a so-called message digest (hash) to calculate a digital signature. The message digest is the resulting value from hashing the information that is being transmitted, and it is basically a summary message of fixed length that describes the main message (regardless of the length of the main message). Message digests are limited to several hundred bits, as specified in the hashing protocol; for example, if MD5 is used, the length of the digest will be 128 bits. Should a single bit value in the transmitted stream of information change, this would result in a totally different message digest value.
HostB receives the information with the signature and performs its own hash calculation, using the same hashing algorithm and supposedly the same information that was submitted. If the resulting hash value matches the one extracted from the signature, HostB sees that the information has not been tampered with in any way. To extract a message digest value from the signature, HostA's public certificate is used. HostA's identity and the authenticity of the submitted information are verified; however, if the two hash values do not match, something has to be wrong with either the source or the information.
Hashing is not flawless. It has been demonstrated a while ago that hashing is susceptible to the so-called birthday paradox, or birthday attack. In certain, extremely rare circumstances, it is possible to evaluate the same hashing algorithm to two identical values, while running it on two completely separate input messages. This is known as hash collision; the chances of this happening are non-zero, but so remote that digital signatures may be admitted as forensic evidence in court.
Similarly to KDC in Kerberos, a Certification Authority (CA) acts as a third party in PKI. All hosts explicitly trust public CAs, and digital certificates are issued by these authorities. For Internet-facing applications and servers, certificates need to be obtained from public CAs. Public CAs are third-party organizations, which are in the business of verifying identities of individuals and organizations who request certificates. A certificate from a public CA will be trusted on all operating systems from any vendor who ships the OS with the issuing CA's information added as a trusted CA.
CAs also maintain CRLs, or certificate revocation lists, which list all certificates that were invalidated administratively before their expiration. Participants who need to use encryption can obtain the counter party's public keys by exchanging certificates, and optionally can run them by the CRLs (this will depend on the particular software configuration).
Digital Certificates (x.509 v3 certs)
Digital certificates are files. These files contain several important components. Most importantly, they contain public key, issue, and expiration dates; subject and subject alternate names (if any); the issuing CA's digital signature; and the certificate's intended uses.
A digital certificate is created by a CA in response to a certificate request. Certificate requests, known as CSRs, are generated by the user or computer that is requesting a certificate. When a CSR is generated, a private key is also created and stored locally. The CSR is submitted to the CA in order for the CA to issue the matching public key. The private key never leaves the system.
Was this article helpful?
Read how to maintain and repair any desktop and laptop computer. This Ebook has articles with photos and videos that show detailed step by step pc repair and maintenance procedures. There are many links to online videos that explain how you can build, maintain, speed up, clean, and repair your computer yourself. Put the money that you were going to pay the PC Tech in your own pocket.