
Archive
Flanagan Consulting
Network Analysts and Consultants
"We Have the Experience"

ViewsLetter on Provisioning 21 July 2003 #25

A fortnightly look at provisioning automationchips to business software.
IN THIS ISSUE:
 Back OnLine with a New List Server
 The Key to Encryption Is Key Management (It's a Provisioning Issue)
>>Analysis
VPN BASED ON ENCRYPTION
DEPENDS ON KEY MANAGEMENT
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
gibberisha 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 (onehalf)(Nsquared)] of keys needed for
symmetrical encryption. The VPN, in particular, must offer
anytoany 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
DiffieHellmans") 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 precalculated 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" exploitvery difficult and
therefore unlikely to affect you. Thieves have easier ways to get
informationbribery, breakins, etc.
A CA should track and publish not only valid certificates, but also
revoked ones. Compromised certificates should be cancelledevery
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.
============ + ===== + ===== + ===== + ============
MORE LINKS
 Visit www.flanaganconsulting.com 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 www.webtorials.com,
your best source for communications tutorials and white papers.
============ + ===== + ===== + ===== + ============
"Flanagan Consulting" and "ViewsLetter" are
Service Marks of W. A. Flanagan, Inc.
Updated: July 2004
