FEATURES

Nortel's Entrust

by DAVID WILLIS

To view theReport card.
Two components must be tightly protected for Entrust to remain secure: the user's login password to the client and the profile (.EPF) file, which is the doorway to the client's identity. Since Entrust requi res well-selected passwords (a mix of upper and lower case, at least eight characters, no substrings of the user's ID, for example), it is fairly resistant to automated brute force attacks.

Users may be tempted to move their .EPF files around to work on different machines. If machine configurations are not locked down well, it's best to keep profiles on carefully guarded disks. For more rigorous security, you can obtain PC Cards from Nortel that eliminate the need to protect the profile file. We'd like to see one-time password generators (such as SecureID, Assurenet Pathways or Enigma Logic tokens) as another option.

On the back end, the passwords for the security officer and the administrator must be carefully guarded. Changing these passwords may require multiple authorizations, at the discretion of the officer. The officer also can set highly stringent pa ssword-selection criteria for officers and administrators--these must be accessed only from the host console. Until Entrust supports secure distrib uted management, these employees need to have physical access to the host. This is another instance when handheld token generators would help for high-security environments.

Entrust is targeted at medium-to-large organizations of more than 100 users that can provide the infrastructure--both in terms of hardware and personnel--to support it. For smaller groups, Entrust/Lite offers the same client functionality without the need for an X.500 directory.

Will Entrust magically create a secure environment, allowing you to forget about security issues? Of course not. It's only a tool to help implement a well-considered information security policy. To be used most effectively, it will require an extensive security awareness campaign. Entrust puts data protection in the hands of trusted individual users. If you think about it, that's the way we handle paper records. Can it be any other way?

David Willis can be reached at dwillis@nwc.com.

WHAT'S REALLY GOING ON HERE?

Entrust appears simple to the user, but there are a lot of gears turning under the hood.

When a file is signed and encrypted, the Entrust/Client:

· Compresses the file (optional).

· Applies the sender's private signing key to the file, creating a message digest with the MD5, MD2 or DSA SHA algorithms.

· Generates a one-time, random symmetric key (used for both encrypting and decrypting) and encrypts the file using CAST or DES.

· Searches Entrust/Server's online database for the encryption public keys of the recipients. If disconnected, keys previously saved in a personal address book or recipient list may be used.

· Encrypts the symmetric key--not the original file--separately for each recipient. (We detected little performance degradation with multiple recipients.)

· Places a table of symmetric keys and recipients at the front of the file.

· Packages the file with an .ENT extension and saves it to a directory or e-mails it to the recipients.

To decrypt and verify the signature, the Entrust/Client:

· Finds the receiving user in the recipient list at the head of the file.

· Decrypts the symmetric key using the recipient's private key.

· Uses the symmetric key to decrypt the encrypted file.

· Uses the public key of the sender to verify the signature on the file.

· Uncompresses the file, if necessary.

DCE: Unifying Your Network Fabric
by Eric Hall with Rivka Tadjer
Return To The Table Of Contents


Updated October 25, 1996


Valley View, Live!

Research and Reports

Storage Virtualization Guide
May 2012

Network Computing: May 2012

TechWeb Careers