Using public key encryption to secure Notes documents (Page 2)

Search DominoPower's 11,441 Lotus-related article archive

Home
EasyPrint
News details

Articles-only

Twitter Feed

Using public key encryption to secure Notes documents (continued)

Continuing this example, I'll say that Mary Smith, John Doe, and Lisa Jones will have access to the three encrypted fields. Mary is the VP of Human Resources, John is the Personnel Director, and Lisa is in charge of payroll. All users who have access to the database through the ACL (Access Control List) will have rights to view the non-encrypted fields.

"PublicEncryptionKeys is an undocumented, reserved field name."

Here's where the process differs from secret key encryption. Instead of creating a secret key and storing the name of that key in the Form Properties dialog box, simply create a field on the form called PublicEncryptionKeys, as in Figure C. PublicEncryptionKeys is an undocumented, reserved field name. You must spell it exactly as shown. Make it a Names field and turn on "Allow multi-values". When a document is saved with that form, any encryptable fields will be encrypted with the public key(s) of the user(s) listed in the field.

FIGURE C

Add a PublicEncryptionKeys field to the form. Roll over picture for a larger image.

So in effect, only the people listed in PublicEncryptionKeys will be able to read the encrypted fields. In our example, we want the field to contain the names Mary Smith, John Doe, and Lisa Jones. For this example I'd make the field hidden and computed to force those values. In your application, it may work better with a visible, editable field so users can choose keys when the document is saved. It works equally well either way. Remember, though, that this technique works only in R5, not in R4.

R4 Public key encryption
The basic idea is the same in R4, but we have more hoops to jump through. If you create a PublicEncryptionKeys field on the form and fill it with one or more names, Notes will crash when the user tries to save the document. To get around this, create a field to hold the keys, but call it PEK. Since PEK is not reserved, Notes won't automatically try to encrypt fields based on it. In addition, you'll need another field called PEKReaders, as shown in Figure D. I'll explain why in a moment.

FIGURE D

Create the PEK and PEKReaders fields. Roll over picture for a larger image.

Set up PEKReaders as a computed Readers field and turn on "Allow multi-values". Set the value of PEKReaders to "LocalDomainServers".

Since Notes won't automatically encrypt the document for us, we need to create an agent that will. Create an agent called Encrypt Documents, and set it up as shown in Figure E.

FIGURE E

Create the Encrypt Documents agent. Roll over picture for a larger image.

It should trigger when documents are created or modified. It should only run on documents created with the relevant form; Employee in this example. This will be a LotusScript agent, so fill in the Initialize event with the code shown below.


Sub Initialize

Dim s As New NotesSession

Dim db As NotesDatabase

Dim doc As NotesDocument

Dim collection As NotesDocumentCollection

Dim item As NotesItem

Dim i As Integer



Set db = s.CurrentDatabase

Set collection = db.UnprocessedDocuments



For i = 1 To collection.Count

Set doc = collection.GetNthDocument (i)

Set item = doc.GetFirstItem ("PEK")

Set item = doc.CopyItem (item, "PublicEncryptionKeys")

Call doc.RemoveItem ("PEK")

Call doc.Encrypt

Call doc.RemoveItem ("PEKReaders")

Call doc.Save (True, True)

Next

End Sub