Home > Articles

This chapter is from the book

Shared Key Technologies

Shared key technologies, including shared key encryption and Kerberos, will be your critical tool for guaranteeing information security principle number one: confidentiality of Web services messages. The following sections discuss the cryptography behind the algorithms, the mechanisms for managing keys, and the relationship between shared key technologies and public key technologies.

Shared Key Encryption

Other synonyms for shared key encryption are frequently used. This technology is sometimes referred to as symmetric encryption or secret key encryption because the same key is used to both encrypt and decrypt the message, and this key must be kept secret from all non-participating parties to keep the encrypted message secret. For clarity and simplicity, in this book we consistently use the term shared key encryption because sender and receiver share the same key, which is distinct from public key encryption where one key is made open and public to the entire world. Shared key encryption is the key technology to achieve the security principle of message confidentiality. Message confidentiality means that no one other than the intended recipient will be able to read a message because it is encrypted strongly enough that no one without the correct key can decrypt it by any other means. We reproduce the shared key encryption diagram from Chapter 1, "Basic Concepts of Web Services Security," here in Figure 3.1.

Figure 3.1Figure 3.1  Shared key encryption.

The key to message confidentiality is in the key, so to speak. Because both sender and receiver must utilize the exact same key (it is shared), this solitary key must somehow be separately and confidentially exchanged so that both parties have it—and no one else does—prior to message exchange. Under other circumstances, you might think you could send the key via U.S. Mail or read it over the phone, but neither of these approaches would be consistent with the goals of computer-to-computer Web services communication. For Web services, this exchange must be made over the same channel that the encrypted messages will flow. Cryptographers and security practitioners have determined that the best way to accomplish this is to encrypt the shared key using public key encryption before exchange. Public key encryption is described in the next section.

Only the shared key is secret, not the encryption algorithm itself. It is very important that the encryption algorithms themselves are public and well scrutinized. In the early days of information security, encryption algorithms were kept strictly secret and proprietary; however, after they were put into use, users found that they had dangerous flaws. Now the field of cryptography understands that the open study of algorithms enhances confidence in the algorithm's security due to the extensive testing and analysis by all the world's cryptographers. A proof of this point is how long the modern shared key encryption algorithms Advanced Encryption Standard (AES) and Triple Data Encryption Standard (3DES) have been in use, withstanding extensive testing with no flaws found.

Without going into extensive mathematical derivations to prove our points (see Appendix A for some details), we need you to take on faith the three most important factors you need to know about shared key encryption:

  • Shared key encryption is much faster than public key encryption.

  • Shared key encryption can operate on arbitrarily large plaintext messages, whereas public key encryption cannot.

  • Shared key encryption utilizes public key encryption to manage distribution of the shared key securely to the recipient.

Shared key encryption uses cryptographic algorithms known as block ciphers. This means that the algorithms work by taking the starting plaintext message and first breaking it into fixed-size blocks before encrypting each block. Two strong encryption algorithms used throughout the software industry are part of the XML Encryption standard: the long-standing 3DES and the relatively new, but highly reviewed and analyzed AES.

DES involves many computationally fast and simple substitutions, permutations, XORs, and shifting on a data block at a time to produce ciphertext from an input plaintext message. The design of DES is so clever that decryption uses exactly the same algorithm as encryption. The only difference is that the order in which the key parts are used in the algorithm is exactly reversed.

DES is 25 years old and still going strong. Part of the reason for this is that DES was designed (and adapted over the years) to work really well in hardware. Numerous companies now include DES chips in their devices. Virtual private networks (VPNs) frequently use 3DES—the stronger version of DES described next—directly in the hardware to create secure IPSec tunnels. DES uses a 64-bit key: 56 effective bits, and 8 bits for parity. DES operates on an 8-byte fixed-block size. In the past decade, weaknesses found in DES have been addressed by 3DES.

NOTE

It is rumored that the NSA has machines costing under $50K that can brute-force crack DES with its 64-bit key in 15 minutes.

3DES saved DES from being abrogated to the cryptography scrap heap by responding to the fact that 256 (72 quintillion) possible keys made plain DES susceptible to a brute-force attack, so the DES algorithm is run three times with a much longer key. 3DES uses a 192-bit key, of which the effective key length is 168 bits. The idea is to use DES three times: sequencing Encrypt-Decrypt-Encrypt with a different third of the 168-bit key used at each stage, as shown in Figure 3.2. This approach makes it relatively slow but very secure; on hardware, relatively slow is still plenty fast. Note that the middle step—Decrypt—does not actually decrypt the ciphertext created by the first step because a completely distinct key is used; it actually scrambles the message further.

Figure 3.2Figure 3.2 How 3DES uses DES encryption three times in succession to be much more secure than DES alone.

AES is the newest shared key encryption standard. AES came out of a government-sponsored contest won by the cryptographers Joan Daemen and Vincent Rijmen (the algorithm was called Rijndael, pronounced "rain doll)." It also works well in hardware and can have keys up to 256 bits long, taking it out of the realm of ever being susceptible to a brute-force attack.

A critical concept for shared key encryption is padding. The blocks that are input to the cipher must be of a fixed size, so if the plaintext input is not already of the correct size, it must be padded. However, you cannot just add random data; to do so, you would need to communicate to the receiver the correct size of the data, which would be a dangerous clue to an attacker. You also cannot just add zeros because the message itself might have leading or trailing zeros. Consequently, padding must include sentinel information that identifies the padding and must not give an attacker any critical information that might compromise the message.

Kerberos

No discussion of shared key technologies would be complete without mention of Kerberos. Kerberos was originally part of MIT's project Athena. The goal set out for Kerberos was real-time authentication in an insecure (the client is not trusted) distributed environment. This technology predates the Web. Plus, it appears to be getting a new lease on life with Microsoft's adoption of it in the base Windows operating system security model. Kerberos is also one of the recognized security tokens—pieces of information used for authentication or authorization added to a SOAP header—in the emerging WS-Security standard, which is presented in Chapter 7, "Building Security into SOAP."

Kerberos is a trusted third-party authentication protocol. Users and services obtain an authentication token called a ticket that they use for identity and shared keys that they use for secure communications. A shared key known only to the server that encrypts tickets. The Kerberos model calls for a centralized authentication server. Kerberos performs centralized key management and administration. The server maintains all users' shared keys and generates session keys whenever two users want to communicate securely. It authenticates the identity of a user who requests access to secure network services. A client must have a valid password and ticket (which only the server can validate) to use any services.

The basic Kerberos authentication flow is as follows:

  1. The client sends a request to the authentication server requesting "credentials" for a given application server. These credentials can be applied directly to an application server or to a ticket-granting server.

  2. The authentication server responds with credentials encrypted with the client's key; it includes a ticket for the server and a session key.

  3. If the ticket is for the ticket server, the client then requests a ticket for the application server from the ticket server.

  4. The ticket server responds with the ticket.

  5. The client transmits its ticket with the client identity and a session key copy encrypted using the server's key to the application server.

  6. The session key is now shared between the client and application server, which authenticates the client and can be used to authenticate the server. It can also be used to encrypt further communication between the two parties.

Kerberos plays an important, but not leading, role in Web services security. Systems running Microsoft Windows frequently use the built-in Kerberos model, which is appropriate only for closed systems, but they still may want to connect to external organizations via Web services. Those external systems need to have their authentication scheme mapped into the Kerberos model for the two organizations to interact.

The WS-Security standard recognizes Kerberos tickets as one of the valid types of security tokens. A very important attribute and goal of WS-Security is to be able to bridge between different security models and trust domains—for example, one system that runs Kerberos connected to another that uses X.509 public key infrastructure.

Limitations of Shared Key Technologies

As we said earlier, shared key technologies fail to solve the problem of scalable key distribution. Shared key algorithms are fast and can handle infinitely large messages; however, both ends of the communication need access to the same key, and you need to get it to your recipient securely. Shared key cryptography also fails to solve the issue of repudiation. At times, you will need to be able to prove that a certain identity created and attests to sending a message (or document) and no one else could have. The sender must not be able to deny having sent this exact document at this moment in time. Shared key cryptography provides no help here.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020