ViewsLetter(SM) on Provisioning

Site Map



  Flanagan Consulting

            Network Analysts and Consultants
                "We Have the Experience"
ViewsLetter on Provisioning    21 July 2003      #25
A fortnightly look at provisioning automation--chips to business software.

-- Back On-Line with a New List Server
-- The Key to Encryption Is Key Management (It's a Provisioning Issue)


--By William A. Flanagan, Editor and Publisher

There's been a huge rise in concern over information security.  In the past year many service providers have added Virtual Private Networks (VPNs) to their portfolios.  Most are based on encryption as the main protection for messages while they cross the Internet.

Most people in IT, MIS, and networking know the rudiments of symmetrical encryption:  an encryption algorithm operates on the plain text using a "key" (some information that fundamentally represents a string of digital bits).  The ciphertext looks like gibberish--a good algorithm will make the characters nearly random (which is why encrypted text doesn't compress).  To recover the original text, an inverse "decryption" process applies the same key to the ciphertext. 

For protecting your PC, hard drive, or selected files on the server, Symmetrical Encryption works very well.  A single user performs both operations, so only one person needs to know the key ("A secret may be kept by two people, but only if one of them is dead.")

Networking assumes at least two people, in different locations, making the key (called a "shared secret" key) much harder to keep secret.  First, how do you deliver a secret key in the first place?  The government used to send armed couriers around the world, regularly bringing sites their new keys.  Now it's common for parts of keys to be sent via different methods:  mail, radio, adoption of a commonly published commodity price, etc.  A spy needs to intercept all the pieces and assemble them in correct order to steal the key.

When an enterprise, Government organization, or VPN service provider has 100,000 employees or customers, neither it nor any user can handle the number [almost (one-half)(N-squared)] of keys needed for symmetrical encryption.  The VPN, in particular, must offer any-to-any privacy, with little or no lead time to distribute a shared key to each pair of parties on a connection.  The solution is the "Public Key Exchange" invented by Diffie and Hellman ("pass the Diffie-Hellmans") and the RSA (Rivest, Shamir, Adleman) encryption algorithm.
For service providers and large organizations, the number of keys for N users drops to N.

Unless you are writing a program that needs to encrypt, you probably don't want to do the real math (see Schneier's book "Applied Cryptography" for more detail).  In rough outline, the process gives each user in the system a pre-calculated private key (that must be kept secret) and a "public key."  The best part is that every user and/or encryption device can get these keys in advance, before knowing with whom a transmission will be encrypted.  The public parts are openly published on a server, included in email signatures, etc.

To send you an encrypted message, I generate an encryption key for "just us" from your "public key" and my "private key."  I don't know your private key, but your public key combined with my private key creates a number unique to us.  To decrypt the message you can regenerate the "just us" value from your own private key and my public key. 

A public key includes the product of two very large prime numbers, and another carefully selected number.  The private key is calculated from modular arithmetic on the two large primes (which are not themselves needed after this calculation, and aren't known to either user).  Security relies on the extreme difficulty of factoring the large public key number into its two prime numbers.

But how can you be sure a public key really belongs to the person who appears to be sending a message?  You ask someone you trust:  a Certification Authority (CA). 

A CA is a server with responsibility for generating pairs of public and private keys, and assigning them to individuals or entities.  How do you know which server to ask?  Its in the Certificate, the "wrapper" that holds your correspondent's public key; the name, organization, etc. of the assigned user;  issuing CA;  expiration date;  and other information.  The CA "signs" this set with its private key, so you can confirm it with the CA's public key. 

How do you know the CA's public key is valid?  Ask a higher (certificate) authority.  Yes, this process is iterative, leading you to a master server for your own organization, or to a global "root" CA (of which there are several). 

Browsers contain a set of public keys (certificates) for various CAs.  They can expire (as many did around Y2K time).  They can also be faked by a "man in the middle" exploit--very difficult and therefore unlikely to affect you.  Thieves have easier ways to get information--bribery, break-ins, etc. 

A CA should track and publish not only valid certificates, but also revoked ones.  Compromised certificates should be cancelled--every time an employee leaves or whenever a private key is exposed.  Good practice requires that a recipient of a certificate check its authenticity and current validity with the appropriate CA. 

All the key generators, CAs, and related encryption devices constitute Public Key Infrastructure (PKI), to support Public Key Encryption (PKE).  The subject is quite complex, and we've only touched on some of the issues.  The main point to take from this issue is that PKI, being automated, seems to be the scalable way to approach key management in large organizations and on public networks.

============ + ===== + ===== + ===== + ============
-- Visit when you need independent review
and verification of network architecture, product positioning, or
your marketing message in the telecom industry.
-- The archive of past ViewsLetters is available from the web site.
-- Special thanks for supporting ViewsLetter to, your best source for communications tutorials and white papers.
============ + ===== + ===== + ===== + ============

"Flanagan Consulting" and "ViewsLetter" are Service Marks of W. A. Flanagan, Inc.
 Updated: July 2004

Flanagan ConsultingSM
W. A. Flanagan, Inc.
45472 Holiday Drive, Dulles, VA 20166
Ph:  +1.703.242.8381
Fx:  +1.703.242.8391