For many organizations, Notes security represents a fundamental change in the protection of network data. Changing the policies and procedures designed for a security system based on something you knowfor example, a passwordto a security
system based on something you ownfor example, an ID fileis difficult for many organizations. Changes affect users, administrators, and management. Policies and procedures must be rewritten.
This chapter discusses some advanced security features of Notes and the impact that Notes security will have on your organization. Several common scenarios illustrate the issues administrators face when planning a Notes installation. The chapter also
discusses new administrator responsibilities, such as creating and backing up ID files. This chapter, along with Chapter 3, provides a basic understanding of the issues involved with security. Chapter 19, "Administering Notes Security," provides
a detailed guide to help administrators in their day-to-day responsibilities.
Until the release of Lotus Notes Release 4.0, one issue faced by administrators or anyone planning a Notes installation was whether to buy the North American version of Notes or the international version. Notes 3.x users with international licenses
can't decrypt messages encrypted using a North American license. Because of this problem, most large corporations used the less-secure international version even in North America, although this meant that some messages were less secure than was possible.
The good news is that all Notes 4.0 license holders, both international and North American, are completely interoperable.
Notes uses 64-bit keys to encrypt messages. For comparison, Pretty Good Privacy (PGP), a freeware e-mail program available on the Internet (commercial versions are available), uses 1024-bit keys. Many cryptoanalysts are taking the position that anything less than 2048 bits isn't secure. In fact, it is unlikely that any system today that relies on software generation of encryption keys is secure.
Unlike most software publishers, Lotus has decided to publish two versions of Lotus Notes, one for the North American market and one for the international market. This is necessitated by U.S. government laws restricting the export of the security
software Notes incorporates. Lotus has licensed the public-key encryption system from the RSA Corporation. The RSA public-key encryption software is classified as munitions under U.S. government law. The US government restricts to 40 bits the key length
used in any public-key encryption software that is going to be exported. The government restricts the key length to make encrypted messages easy to break. This requirement means that 3.x international versions of Lotus Notes have a weaker encryption scheme
than North American versions. The 4.0 international version and the North American version both use 64-bit keys to encrypt messages. Lotus has negotiated an agreement with the U.S. government that gives the government access to 24 bits of an international
key, reducing the effective protection to that of a 40-bit key. 40-bit keys are trivial to break. Anyone with access to a college computer lab has the computing resources needed to decode a message encrypted using a 40-bit key.
Technically it is illegal to install the North American version of Notes on a laptop and carry that laptop out of the United States. As of this writing, several changes in the law were being considered, including a personal exemption law to cover just
this scenario. To date, no one has been prosecuted for carrying software out on a laptop, but it never hurts to know the law. You can easily receive different recommendations concerning this area of the law from different people. Most companies doing
business internationally decide to buy the international version for all users and avoid any problems.
The biggest security risks you face don't involve someone decrypting messages you send back and forth, but that someone will get a copy of your ID file and gain access to your servers. The increase in security that you get by buying the North American
version doesn't affect this risk at all. For this reason, even with Notes 4.0, large organizations should buy the international version. This is just one more example of balancing the needs for security versus the costs involved in providing that security.
You can't rely on technology alone to protect your Notes data. All effective security systems integrate well planned policies and procedures. Policies and procedures are the only way to deal with the largest threat you facethe possibility that
someone within the organization will gain access to confidential information.
When you install a Lotus Notes server, you can set up a password that is required to boot the software. If you don't want to constantly walk from your office to the site housing your Notes servers, you will want your Notes server to boot without human
intervention. The only way to accomplish this objective is to install the Notes server without any password. This system is a potential security leak. Anyone with access to the server has manager access to all databases stored on the server. Without
password protection on startup, your data is completely open to anyone with physical access to the server. This system causes people to rely on physical security and security provided by your operating system to protect your Notes servers.
Windows NT users of Lotus Notes can start Notes automatically without having to enter a password at the Notes consoleand not compromise security. Instead of requiring a password at the Notes console, protect Notes using NTs security. Windows
NT users can start Notes in a session and require a password in order to access programs running in that session. This strategy allows NT users of Notes to set up Notes servers without any Notes password, but still protect the server from unauthorized
access.
OS/2's password setup isn't reliable. OS/2 comes with the capacity to set a keyboard password, and the password can be in effect at startup. In theory, this technique would protect all programs running on the machine from anyone who doesn't know the
keyboard password. However, because bypassing OS/2's startup password is relatively easy, if you are using the OS/2 version of Notes I recommend that you provide physical security for all servers. You should provide physical security for all your Notes
servers in any case. It's a good idea.
This section uses several databases shipped with Notes to demonstrate effective use of Notes security. The key databases that you need to protect are the Name and Address Book, MAIL.BOX, and a personal mailbox.
When setting up security for any database, you need to keep in mind the purpose that that database serves. Included in that purpose are your method of managing that particular database. For example, the Name and Address Book is set up to allow
distributed management, meaning that multiple administrators at different geographic sites should have the ability to add, change, and delete documents in the Name and Address Book. This system allows you to have a single Name and Address Book for use in a
large organization, without requiring a single administrator to be the sole point of contact for administration.
With Notes, you can have multiple administrators with access to the Name and Address Book. In addition, users should have access to their person records. Users can assume part of the responsibility for maintaining their personal information, such as
their address, phone number, and fax number. This technique is certainly less burdensome than some other e-mail programs that force users to manage complete address books, and can significantly reduce the amount of administrative effort required to
maintain a working Notes network.
The default settings for the Name and Address Book accomplish all these goals. The default access is set at author access without giving users the ability to create personal agents and personal folders. The administrator has manager access and can
create and delete documents. Other servers that need to replicate your Name and Address Book also have manager access.
The Name and Address Book also has roles, which provide the capability to create and edit groups, networks, servers, and users. These roles enable you to give administrators limited access, based on their specific job responsibilities. This enables
administrators to specialize and allows organizations to further distribute the responsibility for maintaining the Address Book.
Your procedures for changing the Name and Address Book should detail who has access to the Name and Address Book and their responsibilities. You should log all attempts to make changes to the Name and Address Book.
MAIL.BOX is a special database used by the mail router in the delivery of e-mail, and is scanned by the mail router on a regular basis. Any document placed in MAIL.BOX which has a "send to" field is processed by the mail router. MAIL.BOX holds
Your goal for MAIL.BOX should be to prevent unauthorized access to e-mail. Administrators need to be able to review dead mail but shouldn't be viewing mail in transit. Users should have only the capability to add mail that they want delivered.
Therefore, the default access for a MAIL.BOX file is depositor. Remember that a person with depositor access can create documents but can't view or update any document in the database, including those he creates. The administrators need at least editor
access to view, change, and delete dead mail.
Each user has his own or her own personal mailbox. The mail router places all mail for that person in his personal mailbox. Personal mailboxes are generally stored on a server, although a mobile users might create a replica of his personal mailbox on
his laptop (see Chapter 20, "Supporting Dial-Up Users," for details). A user should be able to access, view, and change any data in his personal mailbox. Most organizations don't want users to change the design of the personal
mailbox, however; therefore, editor access should be provided to users. Editor access gives full rights to the data stored in the database, while preventing any changes to the design or access control list. The administrators need to be able to change the
design and access control list for personal mailboxes and therefore need manager access to the personal mailboxes. This may be a touchy situation, especially concerning mailboxes for executives. Administrators with manager access have the capability to
read and change mail as they see fit. If this is a concern, you may want to provide a special trusted group of administrators with the ability to have access to personal mailboxes. If you create a special group of administrators with access to personal
mailboxes, make sure that only members of this group have access to MAIL.BOX.
Notes security is based on ID files. ID files hold a user's name, his public and private key, and any certificates that he may have (and some other informationsee Chapter 19, "Administering Notes Security," for details). The ID file is
encrypted and requires a password in order to access it.
ID files are created by the administrator, certified by certifiers, and distributed to users. You have two methods of distributing ID files:
The whole process of creating and distributing ID files is fundamentally different from creating and distributing passwords. Passwords used to log on to systems are easy to re-create. Nothing is lost if someone forgets a password; a quick phone call to
the help desk creates a new password. Administrators never need to have access to the password; this isn't true for an ID file.
Take care when planning the creation and distribution of ID files. There is no central collection point for ID files; in most organizations, ID files are distributed throughout the organization, on each user's workstation. Some organizations collect ID
files on a file server, with each user's ID file placed in a protected directory accessible only by that user. Using a file server can help minimize problems associated with widely distributed ID files, but even then mobile users will have to carry copies
of their ID files on their laptops.
Your first step in designing your ID file creation and distribution procedures is to decide whether you are going to store ID files centrally on a file server or distribute them to users. Most organizations distribute ID files to users, although the
author doesn't recommend this method. Most users simply aren't capable of securing their ID files against theft, and wouldn't know if their ID files had been stolen. This situation represents a real threat to the security of your Notes network. If you
elect to store ID files on individual workstations, make sure that your user education is clear on the need to keep these files secure. Storing ID files on a file server has two advantages:
If you elect to distribute ID files, the next decision that you need to make in designing your distribution policy is whether to distribute the ID files using Notes' Name and Address Book or on a floppy disk. The advantage of using the Name and Address
Book is that Notes provides automated support. The ID file is deleted from the Name and Address Book the first time the user accesses his person record. Of course, the user would be forced to use his person record before proceeding with any other usage of
Notes. Distributing ID files on floppy disk provides a ready-made backup copy of the ID file that the user can store and have available should he lose his hard disk.
When a user forgets a password, providing the user with a new password is a relatively easy task. There is no permanent loss of data involved with forgetting a password. A user who loses an ID file faces far more serious consequences. Any data encrypted
using that user's public key is lost forever, because that user's private key is needed in order to decrypt anything that was encrypted with his public key. In addition, replacing a lost ID file entails more administrative burden than replacing a lost or
forgotten password. For this reason, keeping a backup copy of an ID file is a good idea.
There is no way to re-create an ID file once it has been lost. You can have a policy that users keep backup copies of their ID files, but quite often users will forget to update backups when their ID files are updated. It often falls to the
administrator to keep a backup of all ID files that have been issued. Of course, keeping the administrator's copy of ID files updated is also a large task. A compromise used by many organizations is to have administrators keep a backup of the user's
original ID file. This means that the administrator can replace a lost ID file with a backup. The user still must be recertified with any additional certificates that he held in the lost ID file, and get new copies of any encryption keys, but no data is
lost. The one exception to this rule is when the user was storing the only copy of an encryption key. If the only copy of an encryption key is lost, any data encrypted with that key is lost. You may be able to find someone capable of breaking the
encryption even in cases when no key is available, but you certainly can't rely on this scenario.
No perfect solution exists to the problem of replacing a lost ID file. Having users create and keep backups is unreliable, and many users will not understand this requirement. Most users need to perform this task less than once a year, and their
unfamiliarity with backing up an ID file can lead to confusion, or simply choosing not to do the backup. If you choose to have your administrators keep a backup of all ID files, you are forced to provide your administrators with a level of trust that many
organizations may not be willing to do. Administrators with access to backups of the ID files have the ability to use an ID file to read any encrypted mail and to assume the identity of any person. Because identities are based on ID files, access to the ID
file is synonymous with being able to steal the person's identity. Administrator access to backup ID files is a moot point if your administrator is also your certifier, as a certifier can create IDs and assume an identity simply by creating the identity.
There are some steps you can take to secure backup copies of ID files:
Backup copies of ID files should be kept in a secure, locked safenot in the administrator's desk where anyone has casual access. Because ID files are the basis of Notes security, access to ID files must be carefully controlled. ID files are
encrypted and protected with a password, but backup copies of ID files often share a common password. Because you don't want to rely on a single administrator knowing the password to your ID files, this password can become fairly well known throughout the
organization, at least among the administrative staff. Thus, the backup copies of your ID files can become an easy target for hackers wishing to penetrate your security system.
Requiring multiple passwords can minimize the chance that an administrator will use a backup copy of an ID file to impersonate another user. To replace a lost ID file using a copy with multiple passwords, you first make a copy of the backup ID. Two
administrators together can then remove one of the passwords on the ID file and deliver it to the user.
If someone has lost an ID file, and you fear that it may have been stolen, don't just redistribute a backup copy of the ID file. If an ID file is stolen, you need to issue a new ID and prevent anyone from using the old ID file. Before destroying the
backup copy of the ID file, you need to use it to decrypt any data encrypted with the original ID file. Your procedure for decrypting documents using a backup copy of an ID file after someone has lost their ID file should specify that this should take
place only in the presence of the person owning the file. You should be prepared to immediately re-encrypt the files with the new ID file.
Notes ID files are protected by passwords. This strategy leads many organizations to attempt to extend their policies and procedures regarding passwords to the passwords protecting Notes ID filesa waste of company resources. Passwords used to log
on to a system and passwords used to protect an ID file are protecting fundamentally different things. Passwords used to log on to a system are part of an authentication system. A person is identified by presenting the correct user ID/password combination.
A password protecting an ID file is an access control mechanism that attempts to restrict access to the ID file. A password on an ID file isn't involved in authentication at all.
Common policies regarding passwords include the life span of a password, the minimum length of a password, and requirements for both numeric and alpha characters in a password. Policies surrounding passwords are generally designed to make passwords hard
to guess. In traditional password-protected systems, knowledge of a password is all that is needed to gain access to a system. But knowing the password to a person's ID file is useless without having a copy of the ID file. The password alone provides no
access to the Notes system. Only the Notes ID file can provide access to the Notes system.
If someone has a copy of the ID file, but doesn't know the password, he can try to guess the password protecting the ID file. If the hacker has a copy of the ID file, changing the password on an ID file held by one of your users does nothing to the copy
of the ID file held by the hacker. In addition, the hacker is free to attempt to guess as many passwords as he cares to in an attempt to break into the ID file. Because this process takes place on a system disconnected from your service, you have no way of
knowing if someone is attempting to guess a password associated with an ID file. This problem is why Lotus hasn't incorporated a method of forcing users to change the passwords on their ID files. It's simply pointless.
Even though changing passwords on ID files is pointless, in some organizations it is easier to go along than to change policies. Explaining the difference between a log on password and a Notes ID password may be a difficult process in some
organizations. Satisfying your auditors may mean having a policy asking users to change their passwords on their ID files. Even with a policy, Notes provides no way to enforce this policy.
The only recourse you have if an ID file has fallen into unauthorized hands is to create a new public and private key for the user and to issue a new ID file for that user. Before deleting the old ID file, make sure you decrypt all information that was
encrypted using the old ID file, and then re-encrypt this information using the new ID file.
Security audits are concerned with ensuring that a company can track all changes to its databases and has the capability of detecting a security violation when one occurs. When designing your policies and procedures, ask yourself, "How would I know
if a security violation occurred?" To restrict a security audit, you need to know the answer to this question for all databases in your Notes network. You need written procedures for
If you are working in a financial institution, you probably have lived through a few security audits and have experience meeting audit requirements. You probably have already written procedures for controlling updates to your applications and databases.
Similar policies would need to be developed to control updates to your Notes application designs and databases. Keep in mind that a Notes database is data and application in one package and that data, application, and access control are tightly integrated.
Keeping track of all changes to a Notes design and access control list is even more important than tracking code changes for many other applications.
Although authentication and access control form the basis of all security systems, you should record activity so that you can reconstruct any security violations. There are two levels of recording you need to consider:
Logging is simply collecting information about any security-related event, such as logging into a system. Most systems today, including Notes, routinely log this type of information. The second level of monitoring, audit trails, is based on
logging. A log becomes a useful audit trail when it contains context information, such as the time and the specific actions (such as documents accessed) that occurred. For example, knowing that a person attempted to access a server is fine, but
logging the fact that a user attempted to access the system at 10:23, typed in three wrong passwords, along with those three wrong passwords, is far more useful. The second thing that must happen for a log to become a useful audit trail is that the log
must be protected. It must be impossible for the log to be deleted or modified. This includes all users, including administrators.
The Notes log meets the first essential characteristic of an audit trail. It logs essential access-control events and it records much of the context surrounding each event. However, in Notes there is no way to prevent an administrator from changing the
log, so the Notes log in and of itself isn't a foolproof audit trail. There are two reasons why you would want to keep an audit trail:
Notes provides built-in ways for administrators to monitor changes to ACLs. You can configure databases to e-mail all changes to your personal mailbox, or you can set up a central database to record all changes. This feature helps track changes to ACLs,
but isn't a true audit trail.
Typical procedures for updating a Notes design include having servers specifically designated as production servers and not allowing application designers to make changes directly to the production server. By requiring administrators to approve and then
roll out changes, you can track the source and time of all design changes. Figure 4.1 shows the recommended process for updating Notes applications.
Figure 4.1.
You can avoid problems by enforcing a two-step design-update process.
You should provide designer access to production databases only to the administrators with responsibility for the server, not the entire application development staff.
Discovering that a security violation has occurred is more difficult in Notes than in a password-protected system. The primary method used by many organizations to detect attempted break-ins on password-protected systems is to track the number of logon
attempts for a single user ID. Repeated failed attempts to log on are a sign of hackers attempting to break into your system. However, with Notes you have no way of tracking hackers' attempts to guess passwords for ID files. Anyone with a copy of an ID
file can run a guessing program on his or her local machine until finding the password. The Notes server isn't involved in the process of protecting ID files, and therefore can't track attempts to break into a Notes ID file.
Once a hacker gains access to an ID file and has guessed the password for that ID file, he can gain instant access to your Notes systems. His access won't appear any different initially than an ordinary access by the real user. Notes authentication
succeeds because the hacker has the correct certificates. You need to know the typical usage patterns of your users for clues that a hacker is accessing the system. Perhaps the access is being made at an unusual hour for that user, or the hacker may be
attempting to access databases not normally used by that account. Currently, automated tools to detect these user patterns don't exist, making detection difficult in large Notes networks. You should focus your efforts on the critical portions of the Notes
system: the Name and Address Book, mailboxes, and any highly sensitive databases within your organization. Monitoring is a critical part of any security system. For now, Notes relies on administrators randomly scanning log records to notice any particular
potential violations.
Tracking changes to your system requires that all users have and use personal ID files. There is little point in tracking changes if you can't tell exactly who is making the changes. Many organizations try to ease their administrative burden by using a
common ID file for all administrators. This makes changing/creating access control lists easier. Don't do it!!! If you are serious about security, avoid issuing a common ID file to all administrators. Because administrators will make most of the changes to
your database design and access control lists, they represent the most serious security threat. Tracking the person actually making the changes is important for your security audits.
Certifiers are extremely powerful. They can masquerade as any user in your organization. Through the ability to create ID files, certifiers have complete access to your Notes resources. Both Notes servers and Notes clients rely on certificates to
authenticate identities. Authentication succeeds because both the server and client trust a common third partythe certifier who issued the certificate they have in common. Note the word "trust." If the certifier who issued the certificates
isn't trustworthy, your Notes network isn't secure. Choose your certifiers carefully.
If a certifier should leave your corporation under less than ideal circumstances (no post office jokes here, please), you will be faced with the large task of recertifying all users certified by that certifier. You must discard any certificates for
which this certifier had access, and create new certificates for each user. Because you can't know in advance whether you will face this situation, proper planning is required. Luckily, planning can reduce the effort required to recover from a disgruntled
certifier.
One thing your certifiers should never do is certify people by using the organizational certificate. If your organizational certificate is used to certify ID files, you would need to recertify every user in the organization when a certifier left the
company. You should only use the organizational certificate to create organizational unit certificates. ID files should only be certified using organizational unit certificates. This reduces the number of users that must be recertified when a certifier
leaves. Figure 4.2 shows the users who would need to be recertified if the Marketing/L3Comm certifier leaves the company. By using an organizational unit certifier to certify ID files, L3Comm reduces the number of users who need to be recertified. In this
case, only the marketing department needs to be recertified.
Figure 4.2.
Users must be recertified when their certificates can no longer be trusted.
Chapter 3, "Understanding Security," gives the complete background on organization and organizational unit certificates. Chapter 18, "Administering Notes Security," shows you how to create and use organization and organizational unit
certificates.
One other way to reduce the threat posed by certifiers is to require at least two passwords on all certifier ID files. Access to certifier ID files is what gives certifiers the ability to issue certificates. By requiring two certifiers to be present to
use a certifier ID file, you lower the odds that a certifier will create fraudulent ID files for his personal use. You should require two passwords on all organizational unit certifier ID files and three passwords on the organization certifier ID file.
Firewalls protect your company's computers from external threats. This issue generally arises when a company is trying to connect to the Internet, but Internet protection need not be the only use of firewalls within your company. Firewalls can be set up
between divisions of your company. For example, you may want to place a firewall between North American and international divisions.
Firewalls attempt to isolate two networks from each other. Figure 4.3 illustrates a typical firewall. A firewall attempts to prevent unauthorized network packets from passing through to your protected networks. Firewalls are a relatively expensive
security feature, ranging in price from a few thousand to several hundred thousand dollars. Complex firewalls can easily run tens of thousands of dollars in hardware costs alone.
Figure 4.3.
A typical firewall configuration.
If you're looking for a low-cost way to provide moderate protection from Internet attacks, you can use two Notes servers as a firewall. Notes can serve as an effective firewall. A Notes-based firewall is different in nature from typical firewalls.
Typical firewalls rely on rules specified by administrators to filter TCP/IP packets that can enter or exit the network. Notes-based firewalls rely on Notes security features to block attacks. If you decide to use Notes as a firewall, you need to purchase
additional software to provide access to FTP, Usenet newsgroups, the World Wide Web, and e-mail.
Firewalls are designed primarily to prevent TCP/IP network packets from passing through the firewall. An extremely good technique of isolating your internal network from unauthorized TCP/IP packets is to not use TCP/IP on your internal network. Notes
firewalls are based on this technique. The connection between the external server and the internal server shouldn't be a TCP/IP connection. This system forces all traffic from the Internet to be translated into a different protocol. In Figure 4.4, the two
Notes servers are connected with a null modem cable. Notes does all protocol conversions to allow Notes users to access the Internet.
Figure 4.4.
A Notes-based firewall.
You could also set up each server with two network interface cards (NICs). In each server, one NIC runs IPX and one runs TCP/IP. All communications between these two servers is done using IPX. This prevents any TCP/IP packets coming from the Internet to
travel through your server to your internal network. Notes traffic is automatically handled by the Notes server. The Notes server will transfer the data coming in from the Internet to the correct protocol when passing it on to the internal server.
Authorized Notes traffic can pass through, but no TCP/IP packets are allowed into your internal network. In this case, you can use all the security features of Notes to filter the Notes traffic that is allowed into your internal network.
The real benefit to using Notes as a firewall is that it enables you to tightly control access from within the corporation to the Internet. You can use Notes add-on products such as news readers and Web page readers to translate Internet data into Notes
format and provide this data to your employees. Because these add-ins are controlled by your Notes administrator, users who want to access a new portion of the Internet must have your administrator first set up the add-on product to read that portion of
the Internet. This technique enables you to provide unlimited access for business uses, while limiting or eliminating personal access to the Internet. For example, you can limit access to specific Usenet groups by configuring your Notes server to monitor
only the desired groups. In Figure 4.5, the administrator has selected a subset of all possible Usenet groups. Employees can access only the groups stored as a Notes database on the local server.
Figure 4.5.
Notes enables a company to limit access to legitimate Internet resources.
Notes firewalls enable you to filter the traffic going from your internal employees to the Internet. Because all Internet data is translated to/from documents in Notes databases, you can use all of your Notes administrative tools to restrict or monitor
the information being sent and type of access being allowed.
It also makes sense to integrate Internet data into your Notes network. Users will appreciate having the power of Notes to view and search Internet data. By providing a common tool for accessing internal and external data, you eliminate the need to
configure special tools just to access Internet data. Users also appreciateor at least tend to be less dissatisfied withan administrator who does a good job of identifying useful Internet resources and making them available through Notes.
Life isn't full of just good news, though. You do lose some capabilities when you place Notes between your employees and the Internet. You can expect to lose access to some of the latest, greatest Web features. You will only have access to the features
supported by the products that connect Notes to the Internet. Also, Notes isn't designed to be a firewall, and only provides a moderate amount of protection. A complete discussion of firewalls and all the desirable features is beyond the scope of this
book.
For a Notes firewall to be effective at limiting access to the Internet, it must be the only connection from your company to the Internet. Otherwise, employees can use the alternate path to access Internet resources.
As with all Notes servers, Notes firewalls shouldn't be used as file servers, FTP servers, or distributed file system (NFS) servers.
Chapter 22, "Connecting Notes and the Internet," provides additional detail on ways to integrate Notes and the Internet.
Many organizations will never need to worry about encryption. However, data security goes beyond controlling access to data. What if you need to verify that a memo sent two months ago came from the person listed in the "from" field? What if
you need to encrypt your data while it is being sent from the server to the client? You can accomplish these things with Notes.
If you need to send a "For Eyes Only" memo that you want only one person to be able to read, you can encrypt that memo, using your intended recipient's public key. Because you have used the recipient's public key to encrypt a message, only
that recipient's private key can decrypt that message.
When you need to guarantee that a memo came from the person listed in the "from" field, you should use digital signatures. Digital signatures use the user's private key to attach an encrypted field to the memo. If the memo is altered or
changed in any way after the memo has been digitally signed, you can tell. Therefore, you can guarantee months after the memo has been sent that it actually came from the person listed in the "from" field.
Figure 4.6 depicts the process of digitally signing a document. The first step is to apply a mathematical function (known as a hash function) to the document to create a fixed-length fingerprint. This is done in a way that makes it impossible to
know anything about the original document from just the fingerprint. The next step is to use the signer's private key to encrypt the fingerprint. The encrypted fingerprint is the digital signature.
Figure 4.6.
A digital signature is an encrypted fingerprint of the document being signed.
Digital signatures are verified using the public key of the signer. The signature is decrypted to give the original fingerprint. The verifier then generates a new fingerprint based on the current state of the document. Figure 4.7 shows the process of
verifying a signature.
Figure 4.7.
Verifying a digital signature ensures that the document hasn't been changed.
If the document hasn't been changed, and the correct public key is used to decrypt the signature, you know that the document hasn't been changed since the document was signed and you know the identity of the person signing the document.
Notes doesn't by default encrypt data being transmitted over a network. Notes makes the reasonable assumption that either
This is the way most corporations have been operating for many years and is therefore a reasonable assumption for Lotus to make. If these aren't valid assumptions for your network, you can configure Notes to provide its own secure communications
channel.
In order to use digital signatures or privacy-enhanced memos, both users need to have access to a common Name and Address Book. The Name and Address Book is where public keys are stored. Of course, private keys are stored in the ID file, which should be
in a secure place accessible only by the actual owner of that ID file. For example, you digitally sign a memo using your own private key, but someone needs access to your public key stored in the Name and Address Book before they can verify the signature.
The same is true for privacy-enhanced mail. You need access to someone's public key, stored in the Name and Address Book, in order to send that person private mail. This level of coordination, having each person have access to a common Name and Address
Book, is a major drawback to using Notes as a basis for private communications across separate enterprises.
Users can mail copies of encryption keys to other users, but only regular users of encryption are likely to do this.
One question that many organizations have is, "How can we allow users read-access to data while preventing them from printing or copying this data?" Of course, there is no way to absolutely prevent users from copying data that they can read,
because they can always get out a pencil and paper and write down all the information. However, Notes Release 4.0 databases can be set to disable copying via cutting-and-pasting, forwarding, or printing of documents in the database.
Let's wrap up the discussion of the security basics by using the Notes security elements to accomplish some specific goals. These scenarios are meant as illustrations to help you understand the intent behind each of the Notes security features.
You can protect parts of a document by using protective sections. When creating the form, divide the form into sections. For the section that you want to protect, assign a group name that will hold all users with rights to edit that section. The default
access to the database should be author access. Users with author access can create documents and read documents, but not edit documents. Only those sections of your documents specifically granting editor access can be editedand then only by those
users specifically listed in the group name for that protected section.
This ability is often useful in workflow applications. For example, a user may have the right to generate a purchase order document, but shouldn't be allowed to change the document. This technique would prevent someone from changing a purchase order
after it has been authorized. Give author access to the database, but don't create any AuthorNames fields in documents. Users can create documents but, because they aren't listed in an AuthorNames field, they don't have the ability to edit any document.
When you are collecting sensitive information, you want to make sure that users can't read information submitted from other users. In this case, you want to protect documents from everyone except the person who created it. You do this using reader
fields. When the document is created, a reader field that lists the user should be created automatically (using a macro). Don't forget to include any administrative groups and servers that will need access to the document.
If your application uses fields that should be modified only by your programs and macros, you want to protect that field from accidental alteration by users. You can accomplish this by setting the field as calculated and entering the name of that field
in its formula.
As a Notes administrator, you will need to be particularly concerned with the security setup for each database on your server. Security is the primary source of problems in many Notes installations. Notes uses a combination of certificates, public and
private keys, and access control lists to provide a finely granulated level of security. The primary weakness in Notes security (in any security system, actually) is the security policies that your organization chooses to implement. The most likely route
for an attack on your Notes system is to gain access ID files containing the private keys and certificates from your organization. You will need to carefully design and plan out your policies and procedures for managing your ID files. Each organization
will have to balance the costs versus the benefits.
Notes has tightly integrated encryption capabilities based on public-key cryptography technology licensed from RSA. Public-key encryption is the basis for mail encryption, digital signatures, and secure communications channels. Public-key encryption is
useful only when there is a convenient way to exchange public keys. Other Internet software, such as PGP, has already spawned a small industry to support the exchange of public keys. Let's hope that, in the near future, public-key management in
inter-enterprise and extra-enterprise applications becomes easier for Notes. Until that time, privacy-enhanced mail and digital signatures are primarily useful within a single domain. If you need to transmit data between two servers and you don't have a
trusted connection between the two servers, you can use port encryption. The data is decrypted by the receiving server. This eliminates the possibility of anyone eavesdropping on your conversation.