************************************* * * * DB/C Newsletter * * March 2001 * * * ************************************* News and Comments The response to last month's article about sending email with attachments directly from a DB/C DX program has been excellent. We've updated that sample DB/C code to fix a problem. If you downloaded the software before March 8th, I suggest you get the new version. One customer asked about sending formatted text using HTML formatting. The trick to accomplish this is to change the content type of the email text from "Content-Type: text/plain; ..." to "Content-Type: text/html; ...". We've added the following new FAQ at www.dbcsoftware.com: Question: I'd like to find out the version and license information about my copy of DB/C FS or DB/C DX. Answer: Start dbcfs, dbc or dbcc with the -? command line option. Formal DB/C FS 3.0 beta testing will begin in early April. Some of the delay in starting beta testing was caused by the complexity of the key management part of the authentication feature of the TCP/IP communication between the client and server. Because of this complexity, we've removed authentication from DB/C FS 3.0 - it will be in a future release. Note that encryption is still included in DB/C FS 3.0. If you are interested in participating in the DB/C FS 3.0 beta test program, send an email to us at support@dbcsoftware.com. We now recognize that there is going to be quite a bit of confusion with the key management aspect of the authentication feature which will be included in DB/C DX 11.1 Smart Client and in a future release of DB/C FS (both of which are planned for release later this year). This month's article provides an overview of the type of encryption and authentication that will be part of DB/C FS and DB/C DX. If you are interested in an overview and historical perspective of this issue, read the December 1995 DB/C Newsletter. It can be found in file DEC95.TXT at ftp.dbcsofware.com in the /pub/dbcnews directory. don.wills@dbcsoftware.com ****************************************************************************** Public Key Encryption and Authentication Public key encryption and authentication is now an everyday part of the Internet experience. Whenever you do any web transaction using the HTTPS protocol (note the padlock icon at the bottom of your browser), all of the data is encrypted and authenticated using the Secure HTTP protocol. Although they are almost always used together, in this article we'll discuss encryption and authentication separately to keep things as simple as possible. *** Encryption hides data. Someone who intercepts the packets of data that make up the conversation between a client (e.g. a web browser) and a server (e.g. a web site like amazon.com) will not be able to understand the information being transmitted if it is encrypted. There are various types of encryption. In this article, we'll discuss the type of encryption called public key encryption. The data flow for public key encryption happens like this: - The server creates a pair of keys called the public/private key pair. - The server waits for a TCP connection. - The client creates its own public/private key pair. - The client initiates the TCP connection with the server. - The server sends the public key that it generated to the client. - The client sends the public key that it generated to the server. - Then, each packet of data sent by the client is encrypted using the server's public key and each packet of data sent by the server is encrypted using the client's public key. At each receiving end, the private key is used to decipher the packet of data to its original value. Private keys are very private - they are never known outside of the memory of the machine in which they are created. A key is a string of characters. It can be just a few characters or it can be several thousand characters - it depends on the algorithm and on the strength of the encryption. Longer keys are usually associated with stronger (more secure) encryption algorithms. Public key encryption algorithms have these important features: the only way to decipher the data that was encrypted using the public key is by using the private key; and knowing the public key does not reveal the private key. Note that all of this happens without any persistent storage of keys. New key pairs are generated for each TCP/IP connection and then discarded when the connection is terminated. Thus, the user doesn't know anything about the keys. And because the keys are short lived, there is no need to save them in a file. *** The concept of authentication is not quite as simple. Authentication provides assurance that the entity at the other end of the TCP/IP connection is who you think it is. In the following scenario, let's assume that a consumer is going to use her credit card to purchase something from a commercial company's web server. Ignoring encryption, here is an overview how authentication works for an HTTPS transaction: - A trusted third party called a certificate authority (CA) creates a public/private key pair. We'll call these keys the CA public key and the CA private key. The CA distributes the public key with all web browsers. - The company that owns the web server creates a public/private key pair. - The company sends its public key to the CA. The CA creates a certificate which includes the public key of the company, the name of the company and the name of the web server. The CA then 'signs' the certificate with the CA private key and sends the 'signed' certificate to the company via secure means. - The server waits for a TCP connection. - The consumer's browser initiates the TCP connection with the server and sends a unique value to the server. - The server creates a unique certificate from several pieces of information, including the unique value provided by the client. This certificate is then 'signed' by the CA certificate, and then it is encrypted with the server's private key. This unique certificate is sent to the client. - The browser uses the server's public key to decipher the certificate. The fact that it could be decrypted by the server's public key proves that only the server could have created it. The certificate is then 'checked' with the CA public key to prove that it was signed by the certificate which was signed by CA private key. This process depends on a process called 'signing'. Signing is the process of using the private key of a key pair to encrypt something. Then by using the public key of the key pair, another party can decrypt that something. The algorithms used in conjunction with 'signing' keys provide assurance that the only key that could have encrypted the something was the private key of the pair of 'signing' keys. Also notice that only the server was authenticated. The consumer is a complete unknown to the server. *** The most well known certificate authority is a company called Verisign. The cost for a server certificate is typically a few hundred dollars per year. Verisign also provides client certificates if a server needs to validate the clients that are connecting with it. However, instead of using a third party as your certificate authority, in situations where distribution of public keys is controlled (such as to the company's employees or customers), a company can become its own certificate authority. Future releases of DB/C products that will provide authentication that allows for either situation - certificates provided by a commercial third party or by yourself. Look for more information about this topic in future newsletters. ****************************************************************************** DB/C Class Schedule Class: DB/C DX and JX Language Fundamentals Date: June, 2001 Location: To be determined For information, send email to admin@dbcsoftware.com. ****************************************************************************** Subscribing to the DB/C Newsletter If you don't already have the DB/C Newsletter delivered to your email address and would like to have it emailed to you monthly, just send an email message to 'dbcnews-subscribe@dbcsoftware.com'. The newsletter will be delivered to the email address from which the message was sent.