IMPLEMENTATION GUIDE
The basic premise behind this guide is that there will be more than one person needing to use email encryption and decryption and that these individuals need to share the private and public keys.
These are the main decisions:
- How secure (bit size) should be each key?
- How many public keys are needed?
- How will the keys be shared?
- How will the private keys be protected?
- How to ensure good key management?
- How do folks know who "owns" the key?
KEY SIZE
There needs to be at least one master key pair with the highest level of security. This key pair should not be distributed throughout the company but should be reserved for the bulk data transfers via FTP and similar types of EDI. The private key is stored on as few machines as is possible. This public key is provided to trading partners solely for the bulk transfer of data.
The user name on the key should reference the company along with a notation that it is for FTP type usage. The user name should never reference an individual. The associated email address should be a generic email address that will reach the person in charge of administering encryption keys. This allows the company to substitute individuals without invalidating their primary key.
In addition, this key is used to sign the other public keys generated by the company before distribution outside the company. In addition, it would be used to sign the public key of trading partners (after due diligence) before distribution within the company.
The size of keys generated for groups or units within the company should be chosen in accordance with the sensitivity of the information they will be encrypting and exchanging. Most folks are now suggesting at least 1024 bits and higher.
NUMBER OF KEYS
In general, the company-wide FTP key should not be used for email encryption. However, the company's FTP key will be used to sign the unit-level keys as verification that the key is to be used by trading partners when communicating with that unit.
The need or ability of individuals to share the workload will drive the number of keys that must be generated. In general, those that do the same type of work within a work group will need to share the same set of keys. This allows a co-worker to fill in when someone is on vacation without the sending party needing to use a different key to encrypt the email.
Each such workgroup should have their own key pair (public and private). The name on the key reflects both the company and the unit with a comment that it is to be used for encrypting email to that unit. The email address attached to the key should reflect a generic name for the unit rather than a specific individual within the unit.
Should the unit's key become compromised, the company will issue a revocation certificate and a new key. This new key (once signed by the company's FTP key) would be sent to those who routinely communicate with the unit.
KEY SHARING
There are several ways to approach the sharing of keys. Some methods are very labor-intensive for the person who manages the keys.
- Each PC will get a local copy of the key ring.
- Each group or unit will share a key ring with just their keys in it.
- There is one key ring company-wide for email keys shared by everybody.
Once key rings are shared, it is easiest to share them company-wide. Since the unit-level private keys are protected by a pass phrase, sharing will not allow another unit to open and read encrypted email unless they know that particular key's pass phrase.
This means there is just one place for the encryption key manager to load the public keys from trading partners. With the other options, the key manager must decide which public keys should be loaded to each key ring. It may be that they need to be loaded to several key rings. Under the most grievous option, the key manager may have to load the key to each person's PC or send the key to each person for them to load. Having many individuals within the company all loading the same set of public keys gives opportunity for some to be loaded incorrectly or for someone to be missing the latest set of released keys.
Therefore, as the organization grows in size and in the number of keys, it becomes a nightmare to administer anything other than a single organization-wide key ring. This key ring would not contain the private key used for FTP exchanges. However, all other users in the company would point to a single set of public and private keys used at the unit level.
KEY SECURITY
The unit-level private keys are still protected by a pass phrase. Therefore, the security of the unit-level private key is only as good as the pass phrase. Simple or single word pass phrases must be avoided.
Yet, the pass phrase must be somewhat easy to remember or folks will write it down or otherwise compromise the security of the key. The following ideas may help in generating good pass phrases:
- Put together a sentence of several complex words.
- Try to make the sentence catchy but somewhat nonsensical.
- Change the spelling in unexpected ways (knot for not or know for no, etc).
- Substitute numbers for words (8 for eight) and drop associated spaces (or maybe not).
- Include some punctuation - perhaps at odd spots.
- Change the capitalization as the spirit provides opportunity.
- Don't be predictable.
KEY MANGEMENT
There should be one individual in the company that is responsible for the following:
- Generating unit-level keys for the various units.
- Signing the unit-level keys with the company's main FTP key.
- Putting the signed unit-level keys (public and private) on the company key ring server.
- Placing the signed main and unit-level public keys on an approved key server.
- Distributing the signed public keys to the trading partners as appropriate.
- Accepting and verifying the public keys from trading partners.
- Signing a trading partner's main FTP public key after seeing
positive proof it belongs to the trading partner (e.g., building
the web of trust). Perhaps done at a key-signing party.
NOTE: The unit-level keys from the trading partners do not need to be signed by anyone in the receiving organization. Since these are signed by the sender's main FTP key and their main FTP key is signed by the receiving company's main FTP key, the web of trust is built.
- Load the public keys (both signed main and unsigned unit-level)
from the trading partner to the company key ring.
NOTE: The unit-level key must be signed by the trading partner's main key. However, it is unsigned by the local company's main key (see #7).
- Load the signed main public keys from the trading partner to the key ring used by the FTP decryption process.
This ensures that all unit-level keys have been properly signed before distribution. And this also ensures that trading partner keys are verified before release to be used internally.
KEY IDENTIFICATION
The name of the company should be attached to their key. Many times a person's name is on a key being used for corporate encryption. Not only is this confusing ("To which organization does this key belong?"), but when the individual leaves the company they may wish to take "their" key with them. It is far better to have the corporate ID attached.In some cases a corporation may use their key in support of another. This also causes confusion as the trading partner may not associate the name of the intermediary with their partner. The intermediary should use a key that is tied back to the identity of the organization the are supporting.
When an organization decides to use multiple keys, then each key needs additional commentary that ties the key back to the correct group within the organization. Then this happens, the main (and stronger) key needs to be described as such (e.g. "Bulk EDI").
HTML transcript of
implementation_guide.doc
by courtesy of its author Stephen
M. Butler
First Choice Health Network
Seattle, WA USA
Questions/Comments to: info@vibe.at
last update: Sunday, 26-Mar-2006 13:16:56 CEST