3.4 PKI and business solutions

Previous page
Table of content
Next page


3.4 PKI and business solutions

What will all this security do for your business and how will it keep it secure? Let's look at several business scenarios.

  • You are sending important messages to sales reps via the Internet to different parts of the world. These sales reps travel extensively and carry a laptop with them. How can you protect these messages from unauthorized access?

  • Vendors place orders into an Extranet. This Extranet will take the orders and trigger an immediate shipment to the vendor. "But wait," the vendor says. "I did not order 10,000 horseshoes." How can you prove the vendor actually ordered the horseshoes?

  • Your business also sells horseshoes to customers who pay by credit card. How can you keep the credit card information safe and secure during transmission between the customer's browser and your web server (i.e., prevent the bandits from getting the card and expiration data)?

  • Your business has 1,000 users worldwide. You know who these users are, and these users provide at least 80 percent of your sales via the Internet. You have heard from your techie smart people that user names and passwords are not secure without SSL. But these users also need to send encrypted e-mail. Wow! How do you solve this problem?

Before we start to review each scenario, we need to add a disclaimer. These scenarios are here to facilitate a discussion for real-life examples. There are several methods to solve these problems, and the method presented may not necessarily be the right one for your business. As you read in Chapters 1 and 2, you must balance the solutions with your business requirements. These examples are presented here to demonstrate technical solutions. With that said, here they are.

3.4.1 Scenario one

Example: 

You are sending important messages to sales reps via the Internet to different parts of the world. These sales reps travel extensively and carry a laptop with them. How can you protect these messages from unauthorized access?

S/MIME is the solution for this problem. S/MIME has nothing to do with Marcel Marceau. The problem here is that you need to send important messages via the Internet, a potentially dangerous place where someone unscrupulous can easily intercept your messages and decipher them unless you encrypt the message via a method such as S/MIME. Other methods such as PGP may be better, but first a point will be made here and then we will talk more about PGP.

As we said before, S/MIME provides a method to send and receive secure MIME messages. So what exactly is a MIME message? MIME is described in the IETF standard RFC 1521 and explains how an electronic message is formatted. MIME (Multipurpose Internet Mail Extensions) is a set of specifications that describes a method to offer text via various character sets and multimedia. In order to fully understand S/MIME we also need to cover a topic called "certificates." Chapter 7 will take you through a detailed certificate discussion.

Figure 3.5 is an example of a certificate, a digital identity that is linked to a specific user or person. In our example, a certificate will be placed into each user's e-mail system, another is placed into the public directory (the public key), and another is placed into the e-mail client (the private key).

click to expand
Figure 3.5

In our example, Pistol Jack sends a message to Tex Hunter. Jack finds Tex's public key in the directory and sends him a message. Jack's workstation software encrypts the message and it is then sent via the Internet (SMTP) to Tex's workstation (via a service provider and a POP account). When Tex opens the message, it is automatically decrypted. Now Tex can reverse the process. If he has Jack's public key or access to the directory where Jack's key is stored, then Tex can send an encrypted message back to Jack. This process is accomplished by the S/MIME protocol. See these RFCs for more information.

  • S/MIME Version 2 Message Specification (RFC 2311)

  • S/MIME Version 2 Certificate Handling (RFC 2312)

The solution for our first problem is to implement a mechanism to send S/MIME messages between the home office and the person in the field.

3.4.2 Scenario two

Example: 

Vendors place orders into an Extranet. This Extranet will take the orders and trigger an immediate shipment to the vendor. "But wait," the vendor says. "I did not order 10,000 horseshoes." How can you prove the vendor actually ordered the horseshoes?

In this example, the vendor said they did not place the order that you received into your on-line order system. From the Internet perspective, it can be difficult to say exactly who "someone" is. It is easy to impersonate another person, unless a digital certificate is being used.

The same digital certificate that is used for reading encrypted mail can also be used to digitally sign documents. When the document is signed, you can then tell who actually sent the document. With messages sent on the Internet, it is easy to modify the "from" field and spoof the identity of the sender. No problem there. We will require that the sender digitally signs all orders so we can prove that the messages really originated from the vendor. There are many issues to this problem, and we will stick with our case in point, digital signatures. (The assumption is made that the order did arrive and our order processing department did not make an error.) This process of proving who actually sent the message is called "nonrepudiation." This service provides virtually unforgeable evidence that a specific action occurred or, in our case, a transaction was fulfilled. This is all possible via a certificate. (Another assumption made is that the vendor has not lost control of the certificate stay with us on that.) Nonrepudiation can be used by both the sender of the order and the recipient that is, the business receiving the order to prove to a third party (such as a judge) that the sender did indeed send the transaction and also that the recipient received the same transaction that was sent. Remember the MD2 and MD5 message digests? If any one character of a message were changed, then up to half of the message digest would change. It is very difficult to modify a message and keep the message digest the same (for most of the world's population, it is impossible).

In our example (see Figure 3.6), Jack has digitally signed a message and it is sent to Tex. The software that Tex has will automatically attempt to verify that the signature is from Jack via the public directory. Now back to the scenario: If the vendor says that they did not send the order or that the order was for 1,000 horseshoes instead of 10,000, then you have proof that the order was sent for 10,000 horseshoes, thanks to the digital signature that they sent you (and that you required before filling the order).

click to expand
Figure 3.6

3.4.3 Scenario three

Example: 

Your business also sells horseshoes to customers who pay by credit card. How can you keep the credit card information safe and secure during transmission between the customer's browser and your web server (i.e., prevent the bandits from getting the card and expiration data)?

Data is transmitted between your browser and the web server via some type of network and protocol. The network could be your network at the office or a dial-in system from your house. There are also networks that connect to the cable in your house. The protocol that is used in most cases by the Internet is TCP/IP, which we will discuss in a later chapter. Using a packet sniffer, the bandits can hook on to your network or at your ISP and capture your network packets. There are many places on the Internet where someone can "steal" your packets. A network packet, for this discussion, is an envelope of data. Much like you would send a letter in an envelope to a friend via the post office, you would send e-mail via packets of data via a network. This is all done for you with software and protocols. TCP/IP is the underlying protocol of the Internet. So with a packet sniffer, these packets can be captured and read. It is possible to extract all types of information such as the following:

In our discussion of TCP/IP to come, we will see the OSI reference model, which helps us understand the technical aspect of where we should encrypt data. In this chapter we will discuss why we encrypt the data: to establish customer trust and customer confidence. We can enable a feature on our servers called SSL (Secure Sockets Layer). SSL uses encryption technology developed by RSA Data Security, Inc. The encryption is implemented at the network layer so that anyone trying to capture a packet will receive a packet with encrypted data, which would be very difficult to decode or crack. In order to start a secure session between the client and server you need to have set up certificates on both the server and the client.

Today, most browsers used will have some type of "root certificate." This root certificate is a mechanism that identifies what company issues the certificate. There are companies known as (actually, that act as) certificate authorities (CA). These CAs will act as an authority that certifies that the server you are accessing is really the server you want. Say, for example, when you go to http://www.amazon.com/ and purchase something, you want to be sure that you are actually putting your credit card information at amazon.com and not at http://www.fakeyououtwithafalseaddress.com/. The CA will certify that you are talking with the server to which you want to be connected. There are mechanisms that can route you to the wrong server. So, using a CA such as Verisign, you can be sure that you have connected to the correct server. You may ask, "How will I know this?" Here is how it works.

You have a business and you want to set up a secure server that will accept credit cards. Following are the steps to follow:

  1. Install the hardware.

  2. Install the software.

  3. Install the web server (called the "HTTP stack" or "HTTP server").

  4. Set up the application to process the credit card information.

  5. Set up the DNS.

  6. Create a key ring file request for your HTTP server.

  7. Send the key file request to a CA (with payment and some identification on your company).

  8. The CA will certify the request.

  9. The CA will send the request back to you.

  10. You will merge the request into your key ring file.

  11. Now you are ready to turn on SSL.

Now your question is probably, "What is the process to turn on SSL?" The answer for the most part is simple.

  1. Turn on the port (more on that later) and the port number you want to use for SSL. The default port is 443, so turn this setting "on" in your server.

  2. At the URL, enter "https" (note the "s"). Example: http://www.https://www.thisismywebpageanditissecure.com.

There are several methods to enable SSL. You can turn off the main port on a server that will accept HTTP requests: For example, Port 80. You can redirect http requests to SSL. See your server Help file to determine if your server supports these functions. Also, you can force a redirect to SSL in your application.

So how does all this information solve our business problem?

Figure 3.7 shows a browser accessing a server with SSL enabled. The user will use, or be forced to use, https:// in the URL name. The transmission will not be encrypted using SSL.

click to expand
Figure 3.7

Stay with us, and you will see that SSL will keep the transaction safe. You may point out that the credit card information may still not be safe.

True there have been some break-ins where credit card data was stolen. In that case, SSL could have been used and the data still be ripped off. How is that possible? Easy; the transaction was safe, but someone broke into another part of the system and ran off with the credit card data. Security must cover many facets it's not much good if you lock only the front door and have no locks on the back door.

3.4.4 Scenario four

Example: 

Your business has 1,000 users worldwide. You know who these users are, and these users provide at least 80 percent of your sales via the Internet. You have heard from your techie smart people that user names and passwords are not secure without SSL. But these users also need to send encrypted e-mail. Wow! How do you solve this problem?

At some point you have likely received from your browser a pop-up window like the one in Figure 3.8. This is what is known as a "Basic Authentication" dialog box. Typically, the user name is one that a program has assigned to you or that you have assigned to yourself. The Web is full of places that require a user name. The user name is a mechanism that identifies who you are in relation to the program or data you are trying to access. The password is the key that allows you in under that user name. This is a simple and effective mechanism to access "controlled" data, but it is not very secure. In Basic HTTP Authentication, the password is passed over the network neither encrypted nor as plaintext but is "unencoded." Anyone watching packet traffic on the network will not see the password, but it can be easily decoded by anyone who happens to catch the right network packet. Using a packet sniffer, you would monitor the traffic on a network and extract the password, then use a simple decoder to extract the password. You can see an on-line extract of RFC 2617 that explains more of the problem. [1]

click to expand
Figure 3.8

The most serious flaw in Basic Authentication is that it results in the essentially cleartext transmission of the user's password over the physical network. It is this problem that "Digest Authentication" attempts to address.

Because Basic Authentication involves the cleartext transmission of passwords, it should not be used (without enhancements) to protect sensitive or valuable information.

A common use of Basic Authentication is for identification purposes, requiring the user to provide a user name and password as a means of identification, for example, for purposes of gathering accurate usage statistics on a server. When used in this way, it is tempting to think that there is no danger in its use if illicit access to the protected documents is not a major concern. This is only correct if the server issues both user name and password to the users and in particular does not allow the user to choose his or her own password. The danger arises because naive users frequently reuse a single password to avoid the task of maintaining multiple passwords.

If a server permits users to select their own passwords, then the threat is not only unauthorized access to documents on the server but also unauthorized access to any other resources on other systems that the user protects with the same password. Furthermore, in the server's password database, many of the passwords may also be users' passwords for other sites. The owner or administrator of such a system could therefore expose all users of the system to the risk of unauthorized access to all those sites if this information is not maintained in a secure fashion.

Basic Authentication is also vulnerable to spoofing by counterfeit servers. If a user can be led to believe that he is connecting to a host containing information protected by Basic Authentication when, in fact, he is connecting to a hostile server or gateway, then the attacker can request a password, store it for later use, and feign an error. This type of attack is not possible with Digest Authentication. Server implementers should guard against the possibility of this sort of counterfeiting by gateways or CGI scripts. In particular it is very dangerous for a server to simply turn over a connection to a gate-way. That gateway can then use the persistent connection mechanism to engage in multiple transactions with the client while impersonating the original server in a way that is not detectable by the client.

If you want to send the user name and password, then use SSL. This method will encrypt the data at the network level so someone with a sniffer cannot easily decode (decrypt) the data or your passwords.

There is another method that you can use. Remember the S/MIME discussion with Scenario One? We can use the same certificate to provide authentication on the web server. There may be reasons to use both user name and password certificates but not in this discussion. So how can we do this? Following are the high-level steps:

  1. Design a certificate infrastructure.

  2. Create a certification management system. Many web servers and many vendors offer this type of service. Entrust and Verisign are two examples.

  3. Next, get the certificates to the browsers and a directory. Again, this should be part of the certificate management system.

  4. Train the users on the technology! This is critical and will be repeated again and again.

  5. Set up a support system to help the end users and administrators with any problems.

  6. Enable the application to use the certificates.

When the user accesses the web page that is enabled for https, he or she will get a prompt like the one in Figure 3.9. The user will be able to select a certificate. You may have several. Now with the selected certificate, the user can authenticate with the server. The authentication process will occur via a directory source that is internal or external to the web server. Figure 3.10 shows an example of a web server with a directory that is integrated with the web server.

click to expand
Figure 3.9

click to expand
Figure 3.10

In Figure 3.11, the authentication takes place at the LDAP server. The LDAP server offers several services, including directory assistance for e-mail address and authentication. The LDAP server will have the user information along with his or her public key. This key is matched (authenticated) with the authentication credentials that are sent in from the web server to which the user is attempting to get access. An LDAP-formatted query is sent to the LDAP server from the web server. This is called a bind operation. If the authentication is successful, a "Distinguished Name" (DN) is returned back to the web server. This name can then be used for access control to the applications. Note: You can also use the LDAP directory as a source to store passwords for basic authentication if your web server supports it.

click to expand
Figure 3.11

There are several software vendors that will allow you to integrate the Web features and e-mail features under a single package. This package will allow you to share the user certificate between the mailer and the web browser. Thus, this is the solution for your business problem. The users will have access to a directory (again LDAP) for user names and public keys. When they need to send an encrypted message, they only need to select the user name and then tell the mailer to encrypt the message. Now with the same package, the user can then authenticate with the web site that is on the Internet. There is no need for any user name or passwords.

Following is an extra complication that could be a part of this or any of the above business scenarios.

Example: 

The users will need to occasionally send encrypted messages to a small percentage of vendors. Each user may only have one or two vendors to whom he or she needs to send encrypted mail.

As with all these scenarios, several methods exist to solve this problem. Here is a solution: Train the users in the methods to add a new user to their personal address book in their mailer program. Many programs will allow you to add new users. Following are the steps (in this example, a vendor is a single user, not an organization with a single certificate):

  1. The user will tell vendor A to send him or her a digitally signed message.

  2. The user will receive the message and then add the vendor A name to the address, using an action dialog box, button, and/or script.

  3. This script will add vendor A's name, e-mail address, and public key to the user's personal mail directory.

  4. Now the user can send an encrypted message to that particular user (vendor).

  5. Repeat the process for each additional vendor.

  6. The user sends a digitally signed message to vendor A, and vendor A follow the same steps. (Note: There are other options available for large lists of users. This example is for managing single certificates on an exception basis.)

[1]Source: http://www.ietf.org/rfc/rfc2617.txt



Previous page
Table of content
Next page
Internet Security(c) A Jumpstart for Systems Administrators and IT Managers
Internet Security: A Jumpstart for Systems Administrators and IT Managers
ISBN: 1555582982
EAN: 2147483647
Year: 2003
Pages: 103
Authors: Tim Speed, Juanita Ellis
BUY ON AMAZON
Excel Scientific and Engineering Cookbook (Cookbooks (OReilly))
Making Sense of Change Management: A Complete Guide to the Models, Tools and Techniques of Organizational Change
Cisco Voice Gateways and Gatekeepers
101 Microsoft Visual Basic .NET Applications
Microsoft Office Visio 2007 Step by Step (Step By Step (Microsoft))
Understanding Digital Signal Processing (2nd Edition)
flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net
Privacy policy