Building a Secure Journal/Logging Utility with Encryption

Leor Zolman

I don't usually "recycle" ideas from my past writings in other publications, but for this article I decided to make an exception. Back in the June, 1991 issue of The C Users Journal I presented a C program named j, a personal journal utility (as in diary, not the computer science sense of "journal"). That program provided an easy-to-use interface for the creation of dated, sequential entries in cumulative ASCII text files, with support for multiple subject categories. While I created it specifically with personal journal writing in mind, one user later pointed out how the program could be equally useful as a software or system logging mechanism. Such a utility allows a system administrator (or team of administrators) to easily create log entries documenting any information deemed worthy of recording.

The j program turned into one of those perpetual projects for me. When I sat down to make entries in my electronic journal, about as often as not I'd first take some time to modify how j worked; often that left me no time to actually make a journal entry.

I chose C as the original implementation language for j because I was writing for CUJ and wanted to stress portability (in this case, between DOS and UNIX on the source code level). Eventually, I decided to abandon the DOS version and focus on the UNIX implementation in order to take advantage of UNIX's encryption utilities. Without the requirement for DOS support, it became apparent that j is an application better suited to implementation in shell script rather than in C. After all, most of the "work" is done by external programs. All j does is check the environment and command line for controlling parameters, initialize/concatenate files, and call up the text editor and encryption programs as needed. After loading up the original C version with features and struggling to make them all work together, I found that a total rewrite in shell script resulted in a much more coherent piece of code. That shell version is what I present in this article.

Basic Use

The j script has two links, named j and jsee. When invoked as j, it adds new journal text to the current cumulative monthly text file under the invoking user's $HOME/.Journ directory. The jsee link is used to examine and/or modify either the current cumulative text file, or any cumulative text file created by j.

Setting aside the encryption features for now, here is a description of what j does. The first time it is invoked by a user, j checks whether or not the $HOME/.Journ directory exists, and creates it if necessary. Then, j checks if a name argument was given on the command line. If not, j assumes the user wants to add some text to the current default cumulative monthly text file named $HOME/.Journ/yy-mm.ext, where yy is the current two-digit year, mm is the current two-digit month, and ext is an extension dependent upon encryption status (described later). If a name argument was given on the command line, that name is interpreted as the name of a subdirectory of the $HOME/.Journ directory in which the cumulative text file resides (or is to reside). In that case, the full pathname of the cumulative text file to use becomes: $HOME/.Journ/subdir-name/yy-mm.ext.

Once j has figured out which cumulative text file to use, it creates a text file containing a header line with the current date and encryption status, then starts up the text editor to let the user add text to the file to form a complete journal entry. When the user exits the editor, j checks to see if the file has been modified (e.g., the user has saved the work.) If not, no further action is taken -- j assumes the user has decided to abort the journal entry for whatever reason. If the file has changed, then the entire contents are appended to the cumulative text file identified above.

To bring up a previous journal entry, you use jsee. When invoked with no arguments, jsee brings up your text editor with the contents of the current default cumulative monthly journal file, $HOME/.Journ/yy-mm.ext. You may then examine the file's contents and/or edit the file as desired. jsee accepts an optional subdirectory name command-line parameter, similar to j. Unlike j, however, jsee also accepts a straight pathname of a cumulative journal text file, minus the extension, as an argument. If such a name is supplied to jsee, the appropriate encryption extension is tacked on and the result is treated as the pathname of the journal file you wish to examine. For example, the command:

jsee 93-07

would bring up the contents of a file named ./93-07.ext, where ext is an extension dependent upon encryption status. On the other hand, the command:

jsee project1

would bring up the file $HOME/.Journ/project1/yy-mm.ext, where yy-mm are the current year/month, and ext is dependent upon encryption status.

For everyday use as a personal journal manager, the operation of j/jsee couldn't be simpler. To create a new entry, just enter the command:

j

To review the current month's entries, enter:

jsee

Encryption Support

To make my journal entries as secure as possible, I decided to take advantage of UNIX's crypt command to implement automatic encryption/decryption of journal text. This turned into a bigger Pandora's box than I ever could have imagined, due primarily to the inconsistency of crypt features across UNIX platforms. My primary work with j/jsee has been under SCO XENIX and SCO UNIX (two products from the same vendor), yet the crypts from just these two platforms contain a surprising number of dissimilarities that I've had to build in support for. And the crypt command I've experimented with on yet a third Unix platform, Encore UMAX, differs slightly from both the others.

Vanilla crypt

First, I'll to take a look at the common, standard usage of the crypt command. In its basic form, crypt encrypts the plain text provided on its standard input stream and sends the encrypted text to its standard output. The user can specify the encryption key as the only option on the command line. Thus, the command:

crypt foobar <file.1 >file.2

creates a file named file.2 having exactly the same length as the existing file file.1 and containing the text from file.1 encrypted with the key "foobar". To decrypt file.2, the command to use is:

crypt foobar <file.2 >whatever

After execution, a file named whatever should contain exactly the same plain text as was originally contained in file.1.

If the encryption key is omitted, then crypt prompts the user for the key before performing the encryption. This is probably the most secure way of using crypt; however, the way j/jsee works often requires multiple runs of crypt within a single process pipeline, and using the "no key" format is incompatible with such a usage. The only way to avoid the pipeline would be to create temporary files, and that kind of approach opens its own can of security worms.

Up to this point, all versions of crypt I've used display the same behavior, and if this was all the functionality I expected out of crypt, then there wouldn't be any problem. However, invoking crypt with the key on the command line is highly insecure under XENIX, and only marginally secure (sort of like "only a little bit" pregnant) under UNIX. Under XENIX, anyone can list the system process table with full detail using the command

ps -ef

during the entire time that the crypt process is executing. This would reveal the entire command line used to start up crypt -- including the actual encryption key specified by the crypt user. Using SCO's XENIX-specific version of crypt, I've found no way around this "hole".

The UNIX version is a little more careful to wipe out any trace of the encryption key entered on the command line. It accomplishes this by taking advantage of a new feature of crypt specific to the UNIX version: the -k option. In this version, specifying -k in place of a literal encryption key causes crypt to read the actual key out of an environment variable named CrYpTkEy. The assumption in this case is that you've defined and exported CrYpTkEy before running crypt.

The advantage of getting the key from an environment variable is that there is no simple way for any user, including the super-user, to sneak looks into another user's environment. When supplied with a literal encryption key, the UNIX crypt can quickly stuff the string into the required environment variable and then exec a new crypt with -k to overlay the original crypt process and perform the encryption. There would still be a short window of opportunity when someone running ps -ef might be able to see the encryption key, but a user would have to be real fast and lucky to catch a glimpse through that window. Of more concern would be whether or not process accounting is enabled on your system; if so, the system administrator might have access to a record of the original crypt command line with the explicit encryption key spelled out.

The best way I've found to take advantage of the -k option is to provide a way of prompting the user for an encryption key that leaves no revealing process accounting trails for nosy administrators to follow (not that any of us self-respecting administrators would ever stoop that low, of course...), and then to initialize the CrYpTkEy environment variable for use by subsequent crypt invocations. Under XENIX, where -k isn't supported, I've made the interface similar for at least the convenience, if not the security, of the user.

Configuring j/jsee

The greatest complexity of j/jsee is a result of providing the flexibility to adapt to both the differing forms of the crypt command and the varying security needs of users. While you might sense a bit of "overkill" in the range of configuration options, the end result is that once you've set it up to fit your needs, the program will be both easy to use and about as secure as you need it to be.

The comments at the start of the script (Listing 1) provide a complete reference to internal configuration variables and sensitivity to external environment variables. There are three areas involved: encryption control (whether or not to encrypt), getting the encryption key, and supplying that key to crypt as necessary.

Encryption Control

To determine whether or not the user wants the journal text to be encrypted, j/jsee examines its command line, the JCRYPT external environment variable, and the ASK_CRYPT configuration variable.

JCRYPT, the external variable, can be set to Y or N. If Y, j/jsee uses encryption unless (a) the - option appears on the command line, or (b) ASK_CRYPT is Y and the user answers "no" to the encryption prompt.

$ CrYpTkEy=cowabunga_dude

export CrYpTkEy