Encryption in Theory and Practice
By Bruce Busta
In Brief
Understanding the Techniques and Processes
Electronic transactions create business risks for organizations. Internal controls must be evaluated to ensure that electronic transactions are evaluated with respect to confidentiality, integrity, authentication, and nonrepudiation. The author discusses how to achieve these four qualities in an electronic environment. The principles of encryption and the mechanics of the various encryption processes are explained in detail. This article is accompanied by illustrations (in Adobe Acrobat PDF format) of the processes of encyption, which can be downloaded here: Exhibit 2 (Confidentiality) | Exhibit 3 (Integrity) | Exhibit 4 (Authentication and Nonrepudiation) | Exhibit 5 (All Four Concepts) | Exhibit 6 (Obtaining a Digitial ID) | Exhibit 7 (SSL without Client Authentication) | Exhibit 7A (Continued)
Despite the downturn in the dot-com economy, the expansion of Internet-based electronic transactions will move forward. Credit card payments and other online transactions are increasingly common. These electronic transactions create risks that must be evaluated in the auditing process. The issues of confidentiality, integrity, authentication, and nonrepudiation, which have traditionally been evaluated in the course of a paper audit, must now be appraised in the electronic environment.
Basic Techniques
Encryption is the process of taking a message and scrambling it so that only the intended party can read it. Traditionally, encryption has been used by the military to transmit highly sensitive information. Julius Caesar used the first known encryption method, the Caesar Cipher, which simply shifted the alphabet a certain number of characters based on a key known only to Caesar and one of his generals. The Caesar Cipher is an example of a symmetric key algorithm, meaning the same key is used to encrypt and decrypt the message. Although the Caesar Cipher is easy to break, it demonstrates the basic principles of encryption.
Currently, the most common symmetric key algorithm is the Data Encryption Standard (DES), created by IBM in 1977. It is most often used for banking and automated teller machine (ATM) transactions. In DES, the actual message is broken into numerous blocks, each block encrypted and reencrypted several times. Although DES is considered a viable encryption method, it can be broken with today’s technology. In 1997, a cooperative effort on the Internet of more than 14,000 computers cracked a DES message. As a result, the National Institute of Standards and Technology considers DES vulnerable and approved the Advanced Encryption Standard (AES), to be implemented in 2002.
Symmetric key encryption has several limitations. First is the difficulty of managing the keys that must be passed between each party secretly. Each individual the sender wants to communicate with must have a unique key, so a company that wants to communicate with 1,000 customers must have 1,000 unique keys. The advantages of symmetric key encryption are its computational efficiency and its security. A symmetric key encryption method that uses a sophisticated algorithm and a unique key for every communication (a one-time pad) is the most secure form of encryption. Because the pattern of each communication is unique, code breakers cannot determine an underlying pattern.
The Four Objectives of Encryption
The encryption process has four objectives:
To demonstrate these four objectives, consider the Caesar Cipher and the message “Attack in 4 days.”
Confidentiality is obtained by sending the encrypted message “M66MOW UZ G PMB5,” created by shifting the letters of the original message. If the scrambling technique (algorithm) is sophisticated enough, only the general with the key can read the message.
Integrity is not a feature of the Caesar Cipher, but if it were, the change of any character—for example, a change of “G” to “E” (“Attack in 4 days” to “Attack in 2 days”)—in the message would be obvious to the recipient, indicating that the message was modified.
Integrity is a standard feature of all current encryption systems. Basically, a hash total (a value computed on data to detect for error or manipulation) is calculated for the unencrypted message, then the hash total is encrypted and transferred with the text. The recipient reverses the process, and if the hash totals agree, the message was not modified during transmission.
Authentication, which proves to the general that Caesar sent the message, is achieved through the decoding of a readable message. Because only Caesar and his general have the key, the recipient can be confident that the message is authentic.
Nonrepudiation prohibits Caesar from denying that he sent the message—a distinct possibility if the attack goes poorly. Because only Caesar and the general knew the correct key, by decrypting the message received from Caesar with the key, the general can later prove that Caesar sent this message. In today’s environment, the public key infrastructure (PKI) keeps track of which parties own which keys at a certain date, thus enabling nonrepudiation.
Public Key Encryption
Public key encryption (also known as asymmetric encryption) uses two keys: a public key and a private key. These keys—in conjunction with the algorithm and a hashing procedure—accomplish the objectives of confidentiality, integrity, authentication, and nonrepudiation.
The principal feature of a public key encryption method is a “trap door” in the algorithm. This trap door (also known as a one-way function) prohibits text from being decrypted with the same key that encrypted it. This means anyone with a public key can use it to send a secret message, but the message cannot be decrypted by anyone else who has the public key (even the sender). The message can be decrypted only with the private key. This feature means that only two keys are needed in order to send messages to thousands of individuals.
Example. Consider a company in the middle of a critical labor contract negotiation. Management at the corporate office wants to send the message “Accept union proposal, avoid strike” to the management team involved in negotiations at the factory.
The corporate office would use the factory’s public key to encrypt the message sent to the factory. Once the corporate office encrypts the message, it cannot be decrypted with the factory’s public key.
To be certain that the message has not been altered during transmission, a hashing procedure is used. The message is run through a hashing program to produce a message digest. Then the message digest and the message are sent. At the factory, the message is run through the same hashing program. The message digest generated at the factory is compared to the message digest generated at the corporate office. If the message has been altered during transmission, the two digests will not match.
For the factory to be certain that the message is authentic, the corporate office would encrypt the message with its private key and send it to the factory. The factory then decrypts the message with the corporate office’s public key. Because a readable message is produced with the corporate office’s public key, the factory can be confident that the message was encrypted with the corporate office’s private key and could only have come from the corporate office. The PKI assists in this process.
Suppose that after the contract settlement, the parties learn that the union proposal was not fully analyzed at the corporate office and the accepted union contract is significantly more costly than calculated. The corporate office may then want to deny sending the message to the factory. Nonrepudiation is accomplished with the same process as authentication, but record-keeping is critical. The management team at the factory must keep a record of the exact time of the message transmission, the public key used to decrypt the message, and a record of the encrypted message. With this information, the company can demonstrate that the corporate office sent the message, because it can be decrypted with their public key, which was valid at the time of the transmission. This record-keeping process can be complicated. Owners can revoke their keys because they have been compromised or have expired (keys are valid for only a certain period of time). Ensuring nonrepudiation may require the use of old keys and the determination of who was sing which public key at which moment in time.
For the corporate office to send a message that meets all four encryption objectives, a message digest must first be calculated. The message digest is then encrypted using the corporate office’s private key, creating a digital signature that permits authentication and nonrepudiation. Next, the message and digital signature are encrypted with the factory’s public key, providing for confidential transmission. Once received at the factory, the encrypted message and digital signature are decrypted the first time with the factory’s private key, making the message readable. Next, the digital signature is decrypted with the corporate office’s public key. This verifies and permits authentication and nonrepudiation, respectively. Finally, the decrypted and readable message is rehashed to calculate a new message digest. This new message digest is compared to the message digest sent with the message to ensure that the message was not changed during transmission, confirming its integrity.
Secure Socket Layer
Secure Socket Layer (SSL) uses a combination of symmetric and public key (asymmetric) encryption to accomplish confidentiality, integrity, authentication, and nonrepudiation for Internet communications. Introduced by Netscape Communications, SSL has quickly become a popular tool for transmitting credit card numbers, private information, and other sensitive financial data. In a nutshell, SSL uses public key encryption to confidentially transmit a key which can be used to conduct symmetric key encryption.
The SSL session begins when a customer (client) contacts a company (server) using an Internet browser that supports SSL (e.g., Internet Explorer 5.0 or Netscape Communicator 4.x). The browser and the server begin by automatically conducting the “SSL handshake.” The customer’s browser and the company’s server exchange public keys to permit confidential communication and authentication. Additionally, a random number is generated that is used as a secret session key for symmetric key encryption. This secret session key is then confidentially exchanged using public key encryption. Hashing programs provide integrity, and time stamps (coupled with good record-keeping) permit nonrepudiation.
After the public keys and secret key have been exchanged and both parties are authenticated, the SSL handshake is complete. At this time, the customer’s browser will change the security icon from an open lock to a closed lock and the company’s URL will start with “https” to indicate that the server is conducting a secure SSL session.
Future communications between the customer and company are now conducted using the secret symmetric key that the parties confidentially exchanged through public key encryption. Symmetric key encryption is used because its computation efficiency makes it nearly 100 times faster than public key encryption.
Obtaining a digital certificate. To use SSL, at least one party must have a digital certificate, also called a digital ID. A digital certificate verifies that a public key belongs to a certain entity. Without digital certificates, an impostor could distribute a public key and pretend it is the public key for a different company.
When a company wants a digital certificate, it sends its public key and identifying information to a certificate authority. The certificate authority verifies that a certain public key belongs to a specific entity. Verisign, a popular certificate authority, offers several classes of certificates, depending upon the level of scrutiny. After confirming an applicant’s identity, Verisign creates a digital certificate by signing the entity’s information with its private key.
SSL without client authentication. To demonstrate how and why digital certificates are important, consider a customer making an online purchase from Clothes.com. First, initiating the SSL handshake, Clothes.com sends its digital certificate to the customer’s browser, which breaks it into three parts: the signed (encrypted) identifying information, the clear (unencrypted) identifying information, and the public key. The browser verifies that Versign’s private key signed the digital certificate by decrypting the identifying information with Verisign’s public key, which is embedded in the browser. Because the browser can match the signed certificate information with the unencrypted certificate information, the public key belongs to Clothes.com.
In the next step, the customer’s browser generates a random number (also called a secret session key), which is hashed and encrypted with Clothes.com’s public key, then sent to Clothes.com, where it is decrypted with the Clothes.com private key and rehashed. This step ensures that the random number is sent confidentially and with integrity to Clothes.com. This random number becomes the key for symmetric encryption.
Because the customer has not yet confirmed that she is truly communicating with Clothes.com, it returns a message to the customer using the secret session key and a symmetric key algorithm. The message proves that Clothes.com was able to read the secret session key by decrypting it with their private key and authenticates the company. Now that the customer has the secret session key that can be used for symmetric key encryption, the SSL handshake is complete. Credit card numbers, addresses, and other confidential information can now be passed confidentially with integrity over the Internet between Clothes.com and the customer.
The Exhibit demonstrates the SSL procedure when both parties have digital certificates and therefore both are are authenticated. In this example, an investor has an account with an online stockbroker, Stockbroker.com. Because the broker wants to execute only legitimate orders from its customers, authentication is a critical step. Of course, the investor wants to be certain he is interacting with his broker, not an impostor. Traditionally, this is done by requiring the customer to submit a password, but passwords have numerous limitations (easy to guess, easy to forget). Digital certificates can be an excellent alternative.
Assume the investor requires secure communications for a transaction (Step 1). In response, Stockbroker.com sends its digital certificate (Step 2). The investor’s browser opens the digital certificate, breaks it into three parts, and verifies that it actually came from Stockbroker.com (Step 3). Next, the investor’s browser generates a random number that is hashed and encrypted with Stockbroker.com’s public key (Step 4). The encrypted secret session key is sent to the broker, where it is then decrypted and rehashed. Although at this point the secret session key has been transmitted confidentially and with integrity, the possibility of impostors has not been eliminated. Therefore, Stockbroker.com sends a message back to the investor using the secret session key and a symmetric key algorithm (Step 5). Because Stockbroker.com is the only entity that could read the secret session key (using Stockbroker.com’s private key), this step confirms to the investor that he must be communicating with his broker. Step 5 provides authentication and nonrepudiation for the investor.
Because Stockbroker.com has not yet confirmed that it is truly communicating with the investor, Stockbroker.com sends a challenge message asking “Prove you are the investor” (Step 6). The investor responds by sending his digital certificate (Step 7) and the digital signature on the challenge (Step 8). When Stockbroker.com receives the investor’s digital certificate, it breaks it into its three parts and, using the certificate authority’s (Verisign’s) public key to verify the digital certificate, confirms it has the investor’s true public key. Then the broker decrypts the digital signature with the investor’s public key, at which point the digital signature becomes a message digest. Next, Stockbroker.com hashes the challenge. If the resulting message digest matches the message digest received from the investor, Stockbroker.com is assured it is communicating with the investor.
At this point, both parties have achieved authentication and nonrepudiation
(assuming good record-keeping of the algorithm and keys). This completes the
SSL handshake, and both parties exchange further information by using the
secret session key exchanged in Step 4 and a symmetric key
algorithm (Step 9).
The CPA Journal is broadly recognized as an outstanding, technical-refereed publication aimed at public practitioners, management, educators, and other accounting professionals. It is edited by CPAs for CPAs. Our goal is to provide CPAs and other accounting professionals with the information and news to enable them to be successful accountants, managers, and executives in today's practice environments.
Visit the new cpajournal.com.