Cryptographic file security for single domain networks4238854Abstract A file security system for data files associated with a host data processing system. The host system includes a data security device which contains a secure host master key and is capable of performing a variety of cryptographic operations. At initialization time, the host system generates a series of file keys for the associated storage media and protects them by enciphering the file keys under a variant of the host master key. When a data file is to be created, a random number is generated and defined as an operational key enciphered under the file key of a designated storage media. The host data security device, using the enciphered file key of the designated storage media, transforms the enciphered operational key under control of the host master key into a form which permits the operational key to be used for enciphering host data. The operational key enciphered under the file key of the designated storage media, as header information, together with the host data enciphered under the operational key is written on the storage media as an enciphered data file. When the data file is recovered, the host data security device, using the enciphered file key of the designated storage media, transforms the enciphered operational key header information under control of the host master key into a form which permits the operational key to be used for deciphering the enciphered data file to obtain the file data in clear form. Claims What is claimed is: Description CROSS REFERENCE TO RELATED APPLICATIONS
______________________________________
SECURITY
CATEGORY CLASS TYPE USE
______________________________________
Key Encrypting
Keys (KEK)
Primary System Key Host Master
Key (KMH)
Encipher
Secondary Secondary System Secondary
Other
File Keys File Key (KNF)
Crypto-
graphic
Private
Secondary File
Keys
Key (KNFP)
Primary System
File Keys File Key
Data Encrypting (KF) Encipher
Keys Or
Private Decipher
(Operational File Key Data
Keys KO) (KFP)
______________________________________
Generation, Distribution, Installation and Management of Cryptographic Keys Key generation is the process which provides for the creation of the cipher keys required by a cryptographic system. Key generation includes the specification of a system master key and primary and secondary file keys. The host master key is the primary key encrypting key and is the only cipher key that needs to be present in the host cryptographic facility in clear form. Since the host master key does not generally change for long periods of time, great care must be taken to select this key in a random manner. This may be accomplished by using some random experiment such as coin tossing where bit values 0 and 1 are determined by the occurrence of heads and tails of the coin or by throwing dice where bit values 0 and 1 are determined by the occurrence of even or odd rolls of the dice, with the occurrence of each group of coins or dice being converted into corresponding parity adjusted digits. By enciphering all other cipher keys stored in or passed outside the host system, overall security is enhanced and secrecy for such other cipher keys reduces to that of providing secrecy for the single host master key. Secrecy for the host master key may be accomplished by storing it in a non-volatile master key memory so that the host master key need only be installed once. Once installed, the master key is used only by the cryptographic apparatus for internally deciphering enciphered keys which may then be used as the working key in a subsequent encipher/decipher operation. Installation of the host master key may be accomplished by a direct manual entry process using mechanical switches, dials, or a hand-held key entry device. Alternately, an indirect entry method may be used in which case the host master key may be entered from a non-volatile media such as a magnetic card or tape which is maintained in a secure location (safe, vault, etc.) accessible only to the security administrator. Another alternative indirect entry method may be to use a keyboard entry device, though this method is subject to human error. In any event, whichever indirect method is chosen, during initialization, the host master key may be read into and temporarily stored in the host memory and then transferred to the master key memory with the host memory entry being subsequently erased so that only one copy is present and accessible only by the cryptographic facility. The secondary file key is a key encrypting key and since there may be numerous data files associated with the data processing network, it may not be practical or prudent to have these keys generated by a human user using some type of random experiment. Therefore, to relieve the system administrator from the burden of creating cryptographic keys, except for the single system master key, the cryptographic apparatus of the host system can be used as a pseudo random generator for generating the required secondary file keys used by the various data files of the network. The manner by which such host system generated random numbers are produced is described in detail hereafter. In addition to the system generated secondary file keys, off line means may be used by end users to establish a private secondary file key. Because the ciphering algorithm used is not secret, the degree of protection that can be derived from a cryptographic system ultimately depends upon the security of the cryptographic keys. Therefore, the objectives of key management are: (1) cryptographic keys should never occur in clear form outside the cryptographic device, except under secure conditions during the period when keys are originally distributed and installed or when stored in a secure place such as a safe, vault or similar location for backup or recovery and (2) no cryptographic operation, or combination thereof, using any cryptographic quantities which are routinely stored or routed through the system, or derived therefrom, should permit clear keys to be recoverable outside the cryptographic device. Therefore, in keeping with the first objective, if the system generated secondary file keys are to be stored at the host system they must be protected by being enciphered under another key. Accordingly, to prevent exposing these keys in clear form, a dual master key approach is adapted, by the present invention, in which a variant (KMH2) of the host master key (KMH.phi.) is used to encipher the secondary file keys by an Encipher Master Key function (EMK2), which will be described in greater detail hereafter. In the embodiment of the present invention, only the host master key resides in clear form within the cryptographic device. Accordingly, when an EMK2 function is to be performed, the host master key is read out of the master key memory and by selected inversion of certain bits of the host master key the variant KMH2 is derived for use in enciphering the secondary file key. By enciphering the secondary file keys under the variant of the host master key, the enciphered secondary file keys may be stored in a cryptographic data set until required for use in a cryptographic operation and the first objective of key management is obtained, namely, that no key shall occur in clear form. It should be noted that although the relationship between the host master key and its variant are known i. e. which bits are inverted, the cryptographic strength is not weakened because there is no way to use this information to arrive at useful key information because of the complexity of the algorithm. System generated primary file keys, are time variant keys which are dynamically generated for each data file to be created and are used to protect data to be stored. Since there may be numerous data files created it is impractical to have these keys generated by a human user. Therefore, the cryptographic apparatus of the host system may be used as a pseudo-random generator for generating, as each data file is to be created, a pseudo-random number which, in keeping with the objective that cryptographic keys should never occur in the clear, may be defined as being a file key enciphered under the secondary file key. In order to allow the host system to perform an encipher data operation it is necessary to transform the enciphered file key to a form suitable for performing the encipher data operation. This is accomplished by performing a privileged Re-encipher to Master Key transformation function (RTMK), which re-enciphers the file key enciphered under the secondary file key to the file key enciphered under the host master key, in a manner described in greater detail hereafter. Following the transformation function, an encipher function (ECPH) is performed by first performing a decipher key function (DECK) described in greater detail hereafter, in which, using the host master key as the working key, the file key now enciphered under the host master key is deciphered, with the resulting file key, in clear form, being retained in the host cryptographic device and replacing the host master key as the working key for an encipher data operation. An encipher data function (ENC) is then performed to encipher data to be stored in the data file under the file key now available as the working key, described in greater detail hereafter. The file key enciphered under the secondary file key, as header information, and the data enciphered under the secondary file key may now be stored on a storage media as a data file and maintained in a secure manner. When the data file is subsequently recovered, it is necessary to transform the header information to a form suitable for performing a decipher data operation. This is accomplished by again performing the privileged RTMK transformation function to re-encipher the file key enciphered under the secondary file key to the file key enciphered under the host master key. Following the transformation function, a decipher function (DCPH) is performed by first performing a decipher key function (DECK), as described above, for obtaining the file key in clear form, as the working key, after which, a decipher data function (DEC) is performed to decipher the enciphered data recovered from the data file to obtain the file data in clear form. Thus, by enciphering the secondary file key under a second variant of the host master key, both of the objectives of key management are obtained, namely, the secondary file key does not occur in clear form outside the cryptographic device and when used in a cryptographic function it does not permit a clear key to be recovered outside the cryptographic device. In some private cryptographic systems, an end user may wish to use a private secondary file key but still make use of the system facilities for key generation and key management. Thus, in a single domain data processing network, the end user may define a private secondary file key KNFP. At the host, the private secondary file key may be loaded into host, be enciphered under a variant of the host master key to maintain the private key in a secure manner, and then stored in a crypto key data set until such time as a data file is to be created, as in the case of system generated keys. When a data file is to be created or recovered, the private secondary file key is used in the transformation functions and the operation proceeds as in the case of system generated keys. Where limited key management facilities are used with a private end user protocol, it may be necessary to write the enciphered private secondary file key to an output device, such as a printer, and store the printer output in a secure manner, e.g. in a physically protected vault, until such time as the data file is to be created or recovered. At that time, the enciphered private secondary file key is brought out and loaded back into the host system and the operation proceeds as in the previous applications. In other private cryptographic systems, where the end user uses a private protocol which is unknown to the system, key selection, management and data transfer operations are performed without system knowledge that cryptography is being performed. In such arrangements, the end user may define a private protocol using a primary file key, i.e. a private file key KFP. This key is loaded into the host system as a data encrypting key, The private file key is enciphered under the host master key by performing an Encipher Key function (EMK.phi.) and then written to an output device such as a printer and stored in a secure manner e.g. in a physically protected vault, until such time as the data file is to be created or recovered. At that time, the enciphered private file key is brought out and loaded back into the host system. When the file is to be created, an ECPH function is performed to first obtain the private file key, in clear form, and then to encipher the data to be stored in the data file under the private file key whereas when the file is to be recovered, a DCPH function is performed to first obtain the private file key, in clear form, and then to decipher the enciphered data recovered from the data file to obtain the file data in clear form. While it is efficient to use variants of a host master key to provide protection for the various cryptographic keys used in the system, it is well within the skill of the art to provide separate master keys instead of variants of a single master key. This could be accomplished by providing separate master key memories each being loaded with a master which is different from each other and being accessed when needed. While this is a viable alternative, it would substantially increase the cost of the host data security device as opposed to using a single master key memory and obtaining variants as needed. Single Domain Data Processing Networks Modern day data processing networks consist of a single host system which includes a host processor, host memory, channel and its associated resources such as the host programs and locally attached terminals and data files. A representative network is shown in FIG. 1 with the host and its associated resources shown in block form. While the particular manner in which the host system is implemented is not critical to the present invention, the block diagram of FIG. 1 shows the data flow and control relationships of a representative host system arrangement. The host includes a programmable processor 1 operationally connected to a memory 2 which provides storage for data and the programs which are utilized to control the system and a channel 3 which controls the transfer of data between input/output devices and the processor 1. Channel 3 is connected to the processor 1 and memory 2 and via a channel I/O interface, with control units such as control unit 4 capable of controlling an input/output device which may be a printer, control unit 5 capable of controlling a cluster of input/output devices which may be display or printer type of devices, control unit 6 capable of controlling a mass storage device, control unit 9 capable of controlling a plurality of magnetic tape units, control unit 10 capable of controlling a plurality of disk files and a data security device 11. The collection of data and control lines connected between the channel and I/O control units is commonly referred to as the channel I/O interface providing an information format and signal sequence common to all the I/O control units. The I/O interface lines generally include a data bus out which is used to transmit device addresses, commands and data from the processor to the I/O control unit; a data bus in which is used to transmit device indentification, data or status information from the I/O control unit to the channel 3 and tag signal lines which are used to provide signals identifying an I/O operation, the nature of information on the data bus and parity condition. Since each I/O control unit has a unique electrical interface, device adapters are generally provided to allow device connection to the common I/O interface. All I/O data transfers between the processor and the attached control units may be performed in a programmed input/output (PIO) mode on a 1 byte per I/O instruction basis. Into this organization of a general purpose host system is integrated a data security device 11 of the present invention. FIG. 2 shows, in block diagram form, the major elements of the data security device (DSD) 11 which includes a crypto device 12, a master key (MK) memory 13, a DSD adapter 14 which connectes to the I/O interface and a manual entry device 15 for manually loading a host master key into the MK memory 13. Either one of two methods can be used for writing a host master key into the MK memory 13. The first method for writing the host master key into the MK memory 13 is achieved under program control. In this method, an I/O device having a keyboard, magnetic stripe card reader or the like, may use such elements to cause the host master key to be stored in the host memory 2 as in the case of conventional data entry. Subsequently, under program control, the host master key may be read from the host memory 2 to the MK memory 13 of the DSD in a manner which will be described in greater detail hereafter. The other method of writing the host master key into the MK memory 13 consists of manually writing the host master key into the MK memory 13 by means of individual toggle or rotary switches wired to produce binary coded hex digits as will be described in greater detail hereafter. To enable master key writing into the MK memory 13 by either method, an enable write key (EW) switch is provided which is initially turned on when a write master key operation is initiated and turned off at the end of write master key operation. To prevent the key from being changed by unauthorized persons, the EW switch operation may be activated by a physical key lock arrangement. The DSD adapter 14 serves a dual function namely, providing adapter functions for DSD connection to the I/O interface and control functions for the DSD. The I/O interface provides the DSD adapter 14 with overall direction, gives it cipher keys to be used, presents it with data to be processed and accepts the processed results. Overall direction is achieved by use of operation commands which are decoded and subsequently provide control in properly timed sequences of signals to carry out each command. These signals are synchronized with the transfer of data in and out. The DSD adapter 14 also controls the placing of cipher keys in the crypto device 12 and directs the crypto device in the enciphering and deciphering operations. The MK memory 13 in a non-volatile 16.times.4 bit random access memory (RAM) which is battery powered to enable key retention when host power may not be present. The host master key consists of eight maste key bytes (64 bits) each of which consists of seven key bits and one parity bit. The crypto device 12 is the heart of the DSD hardware for performing enciphering and deciphering operations. The crypto device 12 performs encipher/decipher operations on a block cipher basis in which a message block of 8 data bytes (64 bits) is enciphered/deciphered under control of a 56 bit cipher working key to produce an enciphered/deciphered message block of 8 data bytes. The block cipher is a product cipher function which is accomplished through successive applications of a combination of non-linear substitutions and transpositions under control of the cipher working key. Sixteen operations, defined as rounds, of the product cipher are executed in which the result of one round serves as the argument of the next round. This block cipher function operation is more fully described in the aforementioned U.S. Pat. No. 3,958,081. A basic encipher/decipher operation of a message block of data starts with the loading of the cipher key from the host memory 2. This key is generally stored under master key encipherment to conceal its true value. Therefore, it is received as a block of data and deciphered under the master key to obtain the enciphering/deciphering key in the clear. The clear key does not leave the crypto device 12 but is loaded back in as the working key. The message block of data to be enciphered/deciphered is then transferred to the crypto device 12 and the cipher function is performed, after which the resultant message block of enciphered/deciphered data is transferred from the crypto device 12 to the host memory 2. If subsequent encipher/decipher functions are to be performed using the same working key, there is no need to repeat the initial steps of loading and deciphering the working key as it will still be stored in the working key register. The crypto device 12 includes duplicate crypto engines operating in synchronism to achieve checking by 100% redundancy. Referring now to FIG. 3, one of the crypto engines is shown in simplified block form with a heavy lined border signifying a secure area. The crypto engine 16 contains a 64 bit input/output buffer register 17 divided into upper and lower buffer registers 18 and 19 of 32 bits each. The buffer register 17 is used in a mutually exclusive manner for receiving input data on a serial by byte basis from the bus in, termed an input cycle, and for providing output data in a serial by byte basis to the bus out, termed an output cycle. Thus, during each input cycle a message block of eight data bytes is written into the buffer register 17 from the host memory 2 while during each output cycle a message block of eight processed data bytes is read from the buffer register 17 to the host memory 2. Serial outputs of the buffer register 17 are also applied as serial inputs to the working key register 20 and a parity check circuit 21, the latter being controlled to be effective only when a 64 bit clear cipher key is to be loaded directly into the working key register 20 from the host memory 2 via the buffer register 17. Only 56 of the 64 bits are stored in the working key register 20, the 8 parity bits being used only in the parity check circuit 21. The buffer register 17 is also provided with parallel input and output paths from and to a 64 bit data register 22 also divided into upper and lower data registers 23 and 24 of 32 bits each. The upper and lower data registers 23 and 24 each possesses parallel outputs and two sets of parallel inputs. The parallel inputs to the lower data register 24 being from the lower buffer register 19 and the upper data register 23 while the parallel inputs to the upper data register being from the upper buffer register 18 and from the lower data register 24 after modification by the cipher function circuits 25. The 64 bit master key is inputted to the crypto engine 16 on a serial by byte basis with each byte being checked for correct parity by the parity check circuit 26. As in the case of the cipher key transfer from the buffer register 17 to the working key register 20, only 56 of the 64 bits are stored in the key register 20, the 8 parity bits being used only in the parity check circuit 26. During the loading process, the key register 20 is configured as seven 8-bit shift right registers to accommodate the eight 7-bit bytes received from the MK memory 13 (or the buffer register 16). When the working key is used for enciphering, the key register 20 is configured as two 28 bit recirculating shift left registers and the working key is shifted left, in accordance with a predetermind shift schedule, after each round of operation of the cipher function so that no set of key bits once used to perform a cipher operation is used again in the same manner. Twenty-four parallel outputs from each of the two shift registers (48 bits) are used during each round of the encipher operation. The shift schedule provided is such that the working key is restored to its initial beginning position at the end of the complete encipher operation. When the working key is used for deciphering, the key register 20 is configured as two 28 bit recirculating shift right registers and the working key is shifted right in accordance with a predetermined shift schedule, after each round of operation of the cipher function, so that again no set of key bits is used again. As in the enciphering operation, twenty-four parallel outputs from each of the two shift registers (48 bits) are used during each round of the decipher operation. The shift schedule provided in this case is also such that the working key is restored to its initial beginning position at the end of the complete decipher operation. The cipher function circuits 24 perform a product cipher through successive application of a combination of non-linear substitutions and transpositions under control of the cipher working key. Sixteen rounds of the product cipher are executed in which the results of one round serves as the argument of the next round. Deciphering is accomplished by using the same key as for enciphering but with the shift schedule for shifting the key being altered so that the deciphering process is the reverse of the enciphering process, thus undoing in reverse order every step that was carried out during the enciphering process. During each round of the cipher function, the data contents of the upper data register 23, designated R, is enciphered under control of the working key, designated K, with the result being added modulo-2 to the contents of the lower data register 24, designated L, the operation being expressed as L.sym.f(R,K). At the end of the cipher round, the contents of the upper data register 23 is parallel transferred to the lower data register 24 while the output of the cipher function circuits 25 is parallel transferred to the upper data register 23 to form the arguments for the next round of the cipher function. After a total of sixteen rounds, which completes the total cipher function, the contents of the upper data register 23 is parallel transferred to the upper buffer register 18 while the output of the cipher function circuits 25 is parallel transferred to the lower buffer register 19. The transformed data contents of the buffer register 17 is then outputted via the bus out to the host memory 2. DSD Commands and Orders Input/output operations of an I/O device are generally directed by the execution of I/O instructions. In executing an I/O instruction, the channel generally provides an address field for addressing the I/O device, a command field for designating the operation to be performed and another address field for addressing the data field in memory from which data is fetched or to which data is stored. The data security device 11 of the present invention is responsive to seven types of commands from the processor as shown in the following table including the mnemonic and bit pattern of the command:
______________________________________
COMMAND FORMAT
Command
Mne- Field
Name monic 0 1 2 3 4 5 6 7
______________________________________
1. Reset Adapter
RST -- -- -- -- 0 0 1 0
2. Set Basic Status
SET BS -- -- -- -- 0 1 1 0
3. Reset Basic Status
RST BS -- -- -- -- 0 1 0 0
4. Read Basic Status
RD BS -- -- -- -- 0 1 1 1
5. PIOW Data
PIOW -- -- -- -- 1 1 0 0
6. PIOR Data
PIOR -- -- -- -- 1 1 0 1
7. Write DSD
WR
Order DSD w x y z 1 1 1 0
______________________________________
The following is a brief description of the function of each of the commands, the operation of which will be described in greater detail hereafter. 1. Reset Adapter (RST)--This command causes a reset signal to be created to reset all counters, flip-flops and latches in the adapter and control sections of the DSD. 2. Set Basic Status (SET BS)--This command causes those latches in a status register of the DSD that correspond to 1's in the data field to be set to 1. 3. Reset Basic Status (RST BS)--This command is similar to the SET BS command except that the status latches corresponding to 1's in the data field are set to 0. 4. Read Basic Status (RD BS)--This command causes the contents of the status latches to be applied via the data bus in to the processor. 5. PIOW Data (PIOW)--This command causes the data field to be loaded into the buffer register or the bits 0, 1, 2, and 3 of the data field to be stored in the MK memory depending on the operation to be performed. 6. PIOR Data (PIOR)--This command causes an output byte from the buffer register, with correct parity, to be applied via the data bus in to the processor. 7. Write DSD Order (WR DSD)--This command used the four high order bits of the command field to designate cipher key handling and data processing orders as shown in the following table including the mnemonic and bit pattern of the order field:
______________________________________
ORDER FORMAT
Order Command
Mne- Field Field
Name monic W X Y Z 4 5 6 7
______________________________________
Cipher Key Handling
1. Write Master Key
WMK 0 0 0 0 1 1 1 0
2. Decipher Key
DECK 0 1 1 1 1 1 1 0
3. Generate Random
GRN 1 1 1 1 1 1 1 0
Number
4. Encipher Master
EMK.phi.
1 1 0 0 1 1 1 0
Key.phi.
5. Encipher Master
EMK2 1 1 0 1 1 1 1 0
Key 2
6. Reencipher To
RTMK 0 1 0 1 1 1 1 0
Master Key
Data Processing
1. Encipher ENC 1 0 0 0 1 1 1 0
2. Decipher DEC 1 0 1 0 1 1 1 0
______________________________________
DSD Functions DSD cryptographic functions may be performed by combinations of the previously defined commands or by a combination of functions. These functions require an input to the cryptographic apparatus consisting of a key parameter or a data parameter. The notation used to describe these functions will be expressed as follows: FUNCTION[KEY PARAMETER].fwdarw.OUTPUT or FUNCTION[DATA PARAMETER].fwdarw.OUTPUT and when functions are combined, the notation used to describe the combined functions will be expressed as follows: FUNCTION[KEY PARAMETER, DATA PARAMETER].fwdarw.OUTPUT The salient characteristics of host cryptographic functions are that (1) the key parameter, is always in enciphered form and therefore must be internally deciphered by the crypto engine before the clear key is used and that (2) no function allows keys to become available in clear form. The descriptions that follow describe what each function does and how it is performed. These functions will be described in greater detail hereafter but the general description of these functions or combination of functions are given at this point to provide a better understanding of how various security applications may be performed. The descriptions may follow along with reference to FIG. 3 at times. In the diagrams which are referenced in the following, the cryptographic facility is shown in simplified block form for ease of understanding these operations and will be shown and described in greater detail hereafter. Before proceeding to the descriptions of the functions, a brief general description will be given of how the manual write key operation is performed. Referring now to FIG. 4, there is shown a simplified block diagram of a manual WMK operation. In the manual WMK operation, an EW switch is set on to enable writing into the MK memory 13 after which a MW switch is closed to enable manual writing and causing the current master key to be overwritten with whatever happens to be set in the data key entry switches. Following this, 16 sets of 4 bits (64 bits) are manually written into the MK memory 13 to complete the manual WMK operation. Referring now to FIG. 5, there is shown a simplified block diagram of a write master key (WMK) function. This function is carried out by the following sequence of commands: (1) WMK and (2) 16 PIOW's. In this operation, as in the manual WMK operation, the EW switch is previously set on to enable writing into the MK memory 13. The execution of this function causes the current master key in the master key memory 13 to be over-written with whatever happens to be present as bits 0, 1, 2 and 3 on the bus in. Thereafter, the crypto engine controls are set to allow a 64 bit master key KM to be written as a key parameter into the MK memory 13 by means of 16 successive PIOW data commands with the bits 0, 1, 2 and 3 in the data fields associated with the 16 PIOW data commands constituting the new master key. The notation WMK[KM].fwdarw.KM is used to describe this operation whereby the term WMK indicates the function, the contents of the brackets indicate the key parameter input to the MK memory 13 and the arrow points to the result. Referring now to FIG. 6, there is shown a simplified block diagram of a decipher key DECK function. This function is carried out by the following sequence of commands: (1) DECK and (2) 8 PIOW's. The execution of this function sets the crypto engine controls to first allow the master key KM in the MK memory 13 to be transferred to the crypto engine 16 as the working key. After or during the master key transfer, a 64 bit data block, defined as an operational key enciphered under the master key, is loaded as a key parameter into the crypto engine 16 by means of 8 successive PIOW data commands with the successive data fields associated with the 8 PIOW commands constituting the enciphered operational key. After the key parameter loading is completed, the crypto engine 16 performs a decipher operation to obtain the cipher key in clear form. The resultant clear cipher key does not leave the crypto engine 16 but is loaded back into the key register 20 of the crypto engine 16 replacing the master key as the working key. The notation DECK[E.sub.KM KO].fwdarw.KO is used to describe this operation whereby the term DECK indicates the function, the contents of the bracket indicate the key parameter which is inputted to the crypto engine 16 and the arrow points to the result. Referring now to FIG. 7, there is shown a simplified block diagram of an encipher (ENC) function. This function is carried out by the following sequence of commands: (1) ENC (2) 8 PIOW's and (3) 8 PIOR's. The execution of this function sets the crypto engine controls to the encipher mode of operation and allows a 64 bit message block of data to be loaded as a data parameter into the crypto engine 16 by means of 8 successive PIOW data commands with the successive data fields associated with the 8 PIOW commands constituting the message block of data to be enciphered. After the data parameter loading is completed, the crypto engine 16 performs an encipher operation to encipher the data parameter under the operational key presently stored in the working key register of the crypto device 16. The 64 bit enciphered result is transferred by a series of 8 PIOR commands from the crypto engine 16 for storage in designated data fields of the host memory 2. The notation ENC[DATA].fwdarw.E.sub.KO DATA is used to describe this operation whereby the term ENC indicates the function, the contents of the bracket indicate the data parameter input to the crypto engine 16 and the arrow points to the result. Additionally, so long as the crypto engine controls remain set in the encipher mode of operation, then a message which consists of multiple 8 byte blocks of data may be enciphered by the crypto engine 16 by means of an encipher command followed by a series of successive 8 PIOW data commands and successive 8 PIOR data commands for each block of data. This message encipherment may be expressed by the notation: ENC[DATA.sub.1, DATA.sub.2 . . . DATA.sub.N ].fwdarw.E.sub.KO (DATA.sub.1, DATA.sub.2 . . . DATA.sub.N). Referring now to FIG. 8, there is shown a simplified block diagram of a decipher (DEC) function. This function is carried out by the following sequence of commands: (1) DEC (2) 8 PIOW's and (3) 8 PIOR's. The execution of this function sets the crypto engine controls to a decipher mode of operation and allows a 64 bit message block of enciphered data to be loaded as a data parameter into the crypto engine 16 by means of 8 successive PIOW data commands with the successive data fields associated with the 8 PIOW commands constituting the message block of enciphered data to be deciphered. After the data parameter loading is completed, the crypto engine 16 performs a decipher operation to decipher the data parameter under control of the operational key presently stored in the working key register of the crypto engine 16. The 64 bit deciphered result is transferred by a series of 8 PIOR commands from the crypto engine 16 for storage in designated data fields of the host memory 2. The notation DEC[E.sub. KO DATA].fwdarw.DATA is used to describe this operation whereby the term DEC indicates the function, the contents of the bracket indicate the data parameter input to the crypto engine 16 and the arrow points to the results. Additionally, so long as the crypto engine controls remain set in the decipher mode of operation, then a message which consists of multiple blocks of enciphered data may be deciphered by the crypto engine 16 by means of a decipher command followed by a series of successive 8 PIOW data commands and successive 8 PIOR data commands for each block of enciphered data. This message decipherment may be expressed by the notation: DEC[E.sub.KO (DATA.sub.1, DATA.sub.2 . . . DATA.sub.N)].fwdarw.DATA.sub.1, DATA.sub.2 . . . DATA.sub.N. Referring now to FIG. 9, there is shown a simplified block diagram of a generate random number (GRN) function. This function is carried out by the following sequence of commands (1) GRN and (2) 8 PIOR's. Accordingly, in executing this function, the crypto engine controls are set to the encipher mode of operation and a variant KM3 of the master key KM in the MK memory 13 is transferred to the crypto engines 16 as the working key, the variant KM3 being obtained by inverting predefined bits of the master key. During the transfer of the master key variant KM3 to the crypto engine 16, a 64 bit count value CT from a non-resettable RN counter is loaded as a data parameter into the crypto engine 16. After the key and the data parameter loading is completed, the RN counter is stapped by one and the crypto engine 16 performs an encipher operation to encipher the data parameter CT under control of the variant KM3 of the master key presently stored in the working key register of the crypto device 16. The 64 bit enciphered result is a pseudo random number RN which is transferred by a series of 8 PIOR commands from the crypto engine 16 for storage in designated data fields of the host memory for use as a cryptographic key in a manner which will be described hereafter. The notation GRN [CT].fwdarw.RN (E.sub.KM3 CT) is used to describe this operation whereby the term GRN indicates the function, the contents of the bracket indicates the data parameter input to the crypto engine 16 and the arrow points to the result. Referring now to FIGS. 10 and 11, there are shown simplified block diagrams of the encipher master key (EMK.phi.and EMK1) function. This function is carried out by the following sequence of commands (1) EMK.phi.(2) 8 PIOW's and (3) 8 PIOR's or (1) EMK2 (2) 8 PIOW's and (3) 8 PIOR's. Accordingly, in executing these functions, the crypto engine controls are set to the encipher mode of operation causing, in the case EMK.phi. function, the unmodified master key in the MK memory 13 to be transferred to the crypto engine 16 as the working key and, in the case in the EMK 2 function, a variant KM2 of the master key KM in the MK memory 13 to be transferred to the crypto engine 16 as the working key. The variant KM2 is obtained by inverting predefined bits of the master key which are different from those used in the GRN function. After or during the master key transfer, a 64 bit data block, defined as an operational key, in the case of the EMK.phi. command, or as a secondary key encrypting key, in the case of the EMK2 command, is loaded as a data parameter into the crypto engine 16 by means of 8 successive PIOW data commands with successive data fields associated with the 8 PIOW commands constituting the operational key or the secondary key encrypting key. After the key and data parameter loading is completed, the crypto engine 16 performs an encipher operation to encipher the data parameter under the master key or variant of the master key stored in the working key register of the crypto device 16. The 64 bit enciphered result is transferred by a series of 8 PIOR commands from the crypto engine 16 for storage in designated data fields of the host memory. The notation EMK.phi. [KO].fwdarw.E.sub.KM KO is used to describe the EMK.phi. operation while the notation EMK2[KEK].fwdarw. E.sub.KM2 KEK is used to describe the EMK2 operation whereby the terms EMK.phi. and EMK2 indicate the function, the contents of the bracket indicate the data parameter input to the crypto engine 16 and the arrow points to the results. Referring now to FIG. 12, there is shown a simplified block diagram of an encipher data (ECPH) function. This function is a combination of the DECK function and the ENC function and is carried out by the following sequence of commands: (1) DECK (2) 8 PIOW's (3) ENC (4) 8 PIOW's and (5) 8 PIOR's. Accordingly, in executing this function, the crypto engine controls are first set to the decipher key mode of operation by the DECK command causing the master key KM in the master key memory 13 to be transferred as the working key to the working key register of the crypto engine 16. After or during the master key loading, the key parameter of the function, consisting of an operational key enciphered under the master key, is loaded into the crypto engine 16 by means of 8 successive PIOW data commands. The crypto engine 16 then performs a decipher key operation to obtain the operational key in clear form which is then loaded back in as the working key of the crypto engine 16 replacing the previously loaded master key. The crypto engine controls are then set to an encipher mode of operation by the ENC command and the data parameter of the function, consisting of clear data, is loaded into the crypto engine 16 by means of 8 successive PIOW data commands. The crypto engine 16 then performs an encipher operation to encipher the data parameter under the present operational key. The enciphered result is then transferred by a series of 8 PIOR commands from the crypto engine 16 for storage in designated fields of the host memory 2. The notation ECPH[E.sub.KM KO,DATA].fwdarw.E.sub.KO DATA is used to describe this operation whereby the term ECPH indicates the function, the contents of the bracket indicate the successive key parameter and data parameter inputs to the crypto engine and the arrow points to the result. Referring now to FIG. 13, there is shown a simplified block diagram of a decipher data (DCPH) function. This function is a combination of the DECK function and the DEC function and is carried out by the following sequence of commands: (1) DECK (2) 8 PIOW's (3) DEC (4) 8 PIOW's and (5) 8 PIOR's. The first part of this function is identical to that for the encipher data function insofar as loading an operational key in clear form as the working key of the crypto engine 16. After the operational key loading is completed, the crypto engine controls are then set to a decipher mode of operation by the DEC command and the data parameter of the function, consisting of DATA enciphered under the operational key, is loaded into the crypto engine 16 by means of 8 successive PIOW data commands. The crypto engine 16 then performs the decipher operation to decipher the data parameter under control of the present operational key. The deciphered result is then transferred by a series of 8 PIOR commands from the crypto engine 16 for storage in designated fields of the host memory 2. The notation DCPH[E.sub.KM KO,E.sub.KO DATA].fwdarw.DATA is used to describe this operation whereby the term DCPH indicates the function, the contents of the bracket indicate the successive key parameter and the data parameter inputs to the crypto engine and the arrow points to the result. Referring now to FIG. 14, there is shown a simplified block diagram of a reencipher to master key (RTMK) function. This function is carried out by the following sequence of commands: (1) RTMK, (2) 8 PIOW's, (3) 8 PIOW's and (4) 8 PIOR's. Accordingly, in executing this function the crypto engine controls are first set to the decipher mode of operation by the RTMK command an variant KM2 of the master key KM in the MK memory 13 is transferred to the crypto engine 16 as the working key, the variant KM2 being obtained by inverting the same predefined bits of the master key as in the EMK2 function. During or after the transfer of the master key variant KM2 to the crypto engine 16, a 64 bit data block, defined as a key encrypting key enciphered under the same variant of the master key, is loaded as a key parameter into the crypto engine 16 by means of 8 successive PIOW data commands with the successive data fields associated with the 8 PIOW commands constituting the enciphered key encrypting key. After the key parameter loading is completed, the crypto engine 16 performs a decipher operation to obtain the key encrypting key in clear form. The resultant clear key encrypting key does not leave the crypto engine 16 but is loaded back into the key register 20 of the crypto engine 16 replacing the variant KM2 of the master key as the working key. With the crypto engine control still set for the decipher mode of operation, a second dicipher operation is now performed in which a 64 bit data block, defined as an operational key enciphered under the same key encrypting key as is in the key register 20 of the crypto engine 16, is loaded as a data parameter into the crypto engine 16 by means of 8 successive PIOW data commands with the successive data fields associated with the command constituting the enciphered operational key. After the data parameter loading is completed, the second decipher operation is performed to obtain the operational key in clear form. The resultant clear operational key does not leave the crypto engine 16 but is retained in the buffer register 17 of the crypto engine 16. At this time, a special key operation is initiated to allow the master key KM in the MK memory 13 to now be transferred to the crypto engine 16 as the working key. After the master key loading is completed, the clear operational key, presently stored in the buffer register 17 of the crypto engine 16, is transferred to the data register 22 of the crypto engine 16 and a special encipher operation is initiated to set the crypto engine controls for an encipher mode of operation. The crypto engine 16 now performs an encipher operation to encipher the operational key under the host master key to complete the reencipherment function by which the operational key enciphered under the key encrypting key is reenciphered to the operational key enciphered under the host master key. The reenciphered result is transferred by a series of 8 PIOR commands from the crypto engine 16 for storage in designated data fields of the host memory. The notation RTMK [E.sub.KM2 KEK,E.sub.KEK KO].fwdarw.E.sub.KM KO is used to describe this operation whereby the term RTMK indicates the function, the contents of the bracket indicates the key parameter and data parameter input to the crypto engine and the arrow points to the result. File Security Applications The previous section provides a description of the various basic function, command and order capabilities of a host having a data security device capable of performing enciphering and deciphering operations. Accordingly, the following descriptions will provide an explanation of how such a host may be used in various file security applications. While the diagrams used to illustrate these applications are simplified block diagrams, it should be understood that the networks represented by these diagrams are far more complex than that shown. However, this type of representation is used merely to simplify and aid in the understanding of the applications to be described. It should be further understood that the host system contains a full complement of known programming support including an operating system, application programs, a storage access method which, in the present case of single domain networks, directs the transmission of data between host system and data files. File Security in Single Domain Networks Referring now to FIG. 15, there is shown a simplified conceptual block diagram of a single domain data processing network comprising a host system, having a data security device, with the host system having a locally attached storage media such as a magnetic tape or disc for storing data files. At host system initialization time, a primary key encrypting key KMH.phi. is generated in some random manner, as by coin or dice throwing, and then written into the MK memory of the host DSD. Following this, a secondary file key encrypting key, e.g. KEK, is generated in clear form which, if system generated, is designated as a system secondary file key KNF or, if privately generated, is designated as private secondary file key KNFP. The clear system or private generated secondary file key encrypting key KEK is then retained at the host system in protected form by enciphering the secondary file key encrypting key under a variant of the host master key E.sub.KMH2 KEK. To establish a file session between the host system and the storage media, the next step is to generate a primary data encrypting key as a common operational or file key KF. This is initiated at the host system by causing a pseudo-random number to be generated which is defined as being the system file key enciphered under a key encrypting key E.sub.KEK KF. This is in keeping with the rule that no key shall ever appear in the clear. The enciphered file key is retained at the host system for a transformation function during the file session. In order to encipher data for storage in a data file, it is necessary to perform an encipher ECPH function which requires the parameter E.sub.KMH.phi. KF. However, at this point, the file key is enciphered under a key encrypting key other than the host master key, namely, E.sub.KEK KF, where KEK may be the system generated secondary file key KNF or the private secondary file key KNFP. Additionally, the key encrypting key KEK which protects the file key KF is itself protected by being enciphered under a variant of the host master key E.sub.KMH2 KEK. Therefore, in order to obtain the parameter E.sub.KMH.phi. KF for performing the encipher ECPH function, the host system must perform a transformation function. Accordingly, the host system, using the enciphered key encrypting key E.sub.KMH2 KEK, obtained in an authorized manner, and the enciphered file key E.sub.KEK KF, performs a privileged RTMK transformation function which reenciphers the file key from encipherment under the key encrypting key to encipherment under the host master key i.e. from E.sub.KEK KF to E.sub.KMH.phi. KF. Now, having obtained the parameter E.sub.KMH.phi. KF, the host system can encipher data for storage in the data file by performing the encipher ECPH function ECPH [E.sub.KMH.phi. KF, DATA].fwdarw.E.sub.KF DATA. In executing this function, a decipher key operation DECK (E.sub.KEK KF).fwdarw.KF is first performed to obtain the file key in clear form as the working key, after which an encipher data operation ENC(DATA).fwdarw.E.sub.KF DATA is performed on the data to be stored in the data file. Following the completion of the encipher data operation, the parameter E.sub.KMH.phi. KF is erased from the host memory to prevent unauthorized decipherment of the enciphered data. This could be accomplished if an unauthorized person obtained a copy of the data file containing E.sub.KF DATA and a copy of E.sub.KMH.phi. KF if it were retained in the host memory by performing a decipher DCPH function DCPH [E.sub.KMH.phi. KF, E.sub.KF DATA].fwdarw.DATA. By erasing the parameter E.sub.KMH.phi. KF, which is no longer needed to create the data file, this exposure is eliminated. Having now obtained the enciphered file key E.sub.KEK KF and having enciphered the data under the file key E.sub.KF DATA, the host system now causes both the enciphered file key E.sub.KEK KF, as header information, together with the enciphered data E.sub.KF DATA to be written on the secondary storage media as the data file. With this arrangement, the sensitive data is now protected and the file key under which it is protected is also protected and kept as header information with the enciphered data so that the enciphered data may remain protected for relatively long periods of time and be in a form which permits recovery of the data file when necessary. It should be noted that when a new data file is to be created, the host system must establish a new file session by causing a new file key enciphered under the key encrypting key of that file to be generated for establishing a new operational key for the new file session. This procedure provides increased security for the system since the primary file keys are time variant and dynamically generated for each new file session. Thus, it should be apparent that there will be operational key changes for each new file session thereby providing increased security for the system. At a later time, when it is desired to recover the data file and decipher the enciphered data, it is necessary to perform a decipher DCPH function which again requires the parameter E.sub.KMH.phi. KF. However, since this parameter is no longer available, it must be retrieved from the header information in the data file. Accordingly, the data file is read to the host memory and a transformation function must be performed by the host sytem. This is accomplished by using the enciphered key encrypting key E.sub.KMH2 KEK, accessed in an authorized manner, and the enciphered file Key E.sub.KEK KF read from the data file, to perform a RTMK transformation function which reenciphers the file key from encipherment under the key encrypting key to encipherment under the host master key i.e. from E.sub.KEK KF to E.sub.KMH.phi. KF. Now, using the parameter E.sub.KMH.phi. KF, the data file can be deciphered by performing a decipher DCPH function DCPH [E.sub.KMH.phi. KF, E.sub.KF DATA].fwdarw.DATA. In executing this function, a decipher key operation DECK [E.sub.KMH.phi. KF].fwdarw.KF is first performed to obtain the file key in clear form as the working key, after which a decipher data operation DEC [E.sub.KF DATA].fwdarw.DATA is performed on the enciphered data read from the data file to obtain the file data in clear form. It should be noted that at host initialization time, when the data file was to be created, the host system caused a random number to be generated which was defined as the operational key or primary file key enciphered under the secondary file key of the storage media on which the data file is to be created rather than under the host master key. This enciphered file key is then used as a header information in the data file. There are a number of advantages to this arrangement, namely, (1) if the host master key is changed there is no need to change the header information whereas if the file key is enciphered under the host master key, it would be necessary to change the header information everytime the host master key is changed, and (2) if an unauthorized person obtained access to the host system he must still get access to the secondary file enciphered under the variant of the host master key in order to perform the RTMK transformation function which is itself a privileged function. However, this enciphered key is stored in a cryptographic data set which is accessible only in an authorized manner thereby providing another level of security, whereas, if the file key is enciphered under the host master key and an unauthorized person obtains access to the host system he need only perform a non-privileged decipher DCPH function DCPPH [E.sub.KMH.phi. KF,E.sub.KF DATA].fwdarw.DATA to obtain the file data in clear form. Data Management is concerned with the control, retrieval and storage of information to be processed by a data processor. It generally includes an access method which is primarily responsible for organizing and moving information between a host memory and secondary storage media. There are numerous state of the art data management techniques in existence for managing the creation and recovery of data files, none of which are considered critical to the cryptographic techniques of the present invention. Therefore, in order to simplify and aid in understanding the cryptographic techniques of the present invention, as applied to various file security applications, the descriptions which follow assume that the host system contains the normal data management facilities for organizing and moving information between the host memory and secondary storage media and are generally restricted to the cryptographic techniques used to provide file security. Additionally, the descriptions which follow, in connection with FIGS. 16 through 19, are keyed to numbered notations in order to aid in understanding the sequence of operations performed in carrying out the file security application shown in each figure. File Security in Single Domain Networks Using a System Key Referring now to FIG. 16, there is shown in block diagram form, a logical view of file security in a single domain data processing network using a system generated file key. At host initialization time, (1) a host master key (KMH.phi.) is selected and loaded into the MK memory by a manual WMK function or by requesting the execution of a WMK function under host control, (2) the host system then requests a series of GRN functions to be executed to define a series of secondary file keys (KNF.sub.1 -KNF.sub.n) for the storage media associated with the host system. (3) The host system next requests a series of EMK2 functions to be performed to encipher each of the generated secondary file keys under a variant of the host master key (E.sub.KMH2 KNF.sub.1 -E.sub.KMH2 KNF.sub.n) which are then (4) written to a cryptographic key data set (CKDS) along with file ID's for subsequent retrieval when cryptographic operations are to be performed. When a data file is to be created, the host system must obtain a file key and arrange for its transfer to a designated storage media. Accordingly, the host system requests a (5) GRN function to be performed to generate a random number which is defined as the file key enciphered under the secondary file key i.e. RN=E.sub.KNFi KF, of the designated storage media, in keeping with the objective that no key shall occur in clear form, with the enciphered file key being retained in the host memory for subsequent cryptographic transformation function operations. In order to utilize the file key for enciphering data, the host system next requests a (6) privileged RTMK transformation function to be performed. This is accomplished by accessing the CKDS, in an authorized manner, for the enciphered secondary file key E.sub.KMH2 KNF.sub.i of the designated storage media as the key parameter and accessing the host memory for the enciphered file key E.sub.KNF.sub.i KF as the data parameter to perform the privileged RTMK function, whereby the file key enciphered under the secondary file key is re-enciphered to the file key enciphered under the host master key E.sub.KMH.phi. KF. Having derived the quantity E.sub.KMH.phi. KF, the host system now requests that an (7) ECPH function be performed to encipher host data to be stored on the designated storage media using the file key now enciphered under the host master key. Following completion of the encipher data operation, the parameter E.sub.KMH.phi. KF is erased from the host memory in order to prevent unauthorized persons from gaining access to this information and using it to decipher the enciphered data by a decipher DCPH function. (8) The host system now causes the enciphered file key E.sub.KNFi KF, as header information, together with the enciphered host data E.sub.KF DATA to be written on the secondary storage media as a data file. Optionally, instead of writing the enciphered file key to the storage media, the enciphered file key can be written to an output device i.e. a printer, with the output being offloaded and treated as a personal key. Under these circumstances, access to the enciphered data can be controlled or additionally controlled by the means by which the enciphered file key is maintained secret e.g. in a physically secure vault, until the data file is to be recovered. (9) When the data file is to be recovered, the file is read to the host system and optionally, if the enciphered file key had been offloaded and maintained in secrecy as a personal key, the enciphered file key is loaded via an input device into the host system. (10) The host system now performs a privileged RTMK transformation function using the enciphered secondary file key E.sub.KMH2 KNFi for the designated storage media, accessed from the CKDS in an authorized manner, and the enciphered file key E.sub.KNFi KF read from the data file or loaded via the input device to reencipher the file key from encipherment under the secondary file key to encipherment under the host master key i.e. from E.sub.KNFi KF to E.sub.KMH.phi. KF. (11) The host system, now using the parameter E.sub.KMH.phi. KF can decipher the data file by performing a decipher DCPH function to obtain the file data in clear form. File Security in Single Domain Networks Using a Private Key Referring now to FIG. 17, there is shown in block diagram form, a logical view of file security in a single domain data processing network using a private key. There are many situations where it may be desired to provide file security in a data processing network using a private secondary file key i.e. KMTP, which is not system generated but is predefined by an end user. In this case, the end user uses the system for generating the file key and key management for performing the transformation functions and the encipher/decipher data operations. Therefore, in this case, at host initialization time (1) a host master key KMH.phi.) is again selected and loaded into or may already reside in the host MK memory. (2) The end user defines the private secondary file key (KNFP) to be used in the file session (3) This value is then loaded into the host memory and the host requests an EMK2 function to be performed to encipher the private key under a variant of the host master key E.sub.KMH2 KNFP which is then (4) written out to the CKDS along with a file ID for retrieval in subsequent cryptographic operations. The balance of the operation to create and recover the data file is identical to that described above in connection with the system generated key system of FIG. 16. File Security in Single Domain Networks Using a Private Key and Private End User Protocol Referring now to FIG. 18, there is shown in block diagram form, a logical view of file security in a single domain network using a private key and a private end user protocol. In some situations, a private level of file security can be established using a protocol whereby key selection and management are the user's responsibility and requests for cryptographic service are explicitly expressed by the end user. Therefore, in this case, as in the last example, at host initialization time (1) a host master key (KMH.phi.) is selected and loaded into or may already reside in the host MK memory. (2) The end user again defines the private secondary file key (KNFP) to be used in the file session. (3) This value is then loaded into the host memory and (4) a request is made to perform an EMK2 function to encipher the private key under a variant of the host master key E.sub.KMH2 KNFP. However, in this instance, since cryptographic services are explicitly expressed by the end user rather than the system, the resultant value is not written out to a CKDS but rather (5) to an output device e.g. a printer, where the enciphered version of the private key is (6) stored in a secure manner e.g. a vault, until such time as a data file is to be created. At that time, the copy is taken out of whatever secure area it was stored in and (7) the enciphered version of the private key is loaded into the host memory for subsequent use when cryptographic services are requested. In this case, since the private end user protocol has established that requests for cryptographic services are to be expressed by the application program, the application program then requests the (8) GRN function to be performed to obtain a random number defined as the enciphered file key i.e. RN=E.sub.KNFP KF, the (9) RTMK function to be performed to transform the file key enciphered under the private secondary file key E.sub.KNFP KF to the file key enciphered under the host master key E.sub.KMH.phi. KF and the (10) encipher ECPH function to be performed to encipher the host data, for storage in the designated storage media, after which the parameters E.sub.KMH.phi. KF and E.sub.KMH2 KNFP are erased from the host memory in order to prevent unauthorized decipherment of the enciphered host data. (11) The enciphered host data E.sub.KF DATA together with the enciphered file key E.sub.KNFP KF, as header information, are again written on the designated storage media as a data file (or the enciphered file key is optionally offloaded as a personal key). (12) At a later time, when the data file is to be recovered, the enciphered version of the private secondary file key is again taken out of its securely stored area and loaded into the host memory for subsequent use when cryptographic services are requested. (13) The data file is then read to the host system providing the enciphered data file together with the enciphered file key header information (or optionally from an input device if it had been offloaded as a personal key when the data file was created). (14) The application program then requests the RTMK function to again be performed to transform the file key enciphered under the private secondary file key E.sub.KNFP KF to the file key enciphered under the host master key E.sub.KMH.phi. KF after which a request is made to perform the (15) decipher DCPH function to decipher the data file to obtain the file data in clear form. File Security in Single Domain Networks Using a Private Key and a Totally Private Protocol Referring now to FIG. 19, there is shown in block diagram form a logical view of file security in a single doamin data processing network using a private key and a private protocol which is totally private and therefore unknown to the system. In totally private systems, key selection, key management and data transfer is accomplished without system knowledge that cryptography is being performed. Whatever cryptography is performed is known only to an application program. Therefore, in this case, at host initialization time, (1) a host master key (KMH.phi.) is selected and loaded into or already resides in the host MK memory. (2) The end then defines a private file key KFP to be used as an operational key. (3) This value is then loaded into the host memory and the application program request an (4) EMK.phi. function to be performed in order to encipher the private file key under the host master key E.sub.KMH.phi. KFP. The resulting enciphered value is not written out to a CKDS but rather to an output device i.e. a printer device, and (6) the copy of the enciphered file key is stored in a secure manner e.g. a vault, until such time as a data file is to be created. At that time, the copy is taken out of whatever secure area it was stored in and (7) the enciphered private file key is loaded into the host memory for subsequent cryptographic service. The application program next requests an (8) ECPH function to be performed to encipher host data using the enciphered private file key KFP as the operational key to obtain enciphered data E.sub.KFP DATA for transfer to the storage media. (9) The enciphered host data E.sub.KFP DATA is then written on the designated storage media as a data file. (10) When the data file is to be subsequently recovered, the enciphered private file key is again taken out of its securely stored area and loaded into the host memory for subsequent use when cryptographic service is requested. (11) The data file is now read back to the host system and the application program then requests (12) a decipher DCPH function to be performed to decipher the data file to obtain the file data in clear form. DETAILED DESCRIPTION--HOST DATA SECURITY DEVICE Data Security Device Referring now to FIG. 20, there is shown the logic details of a clock pulse generator 100 used in the DSD of the present invention. The primary input is a square wave oscillator whose nominal repetition rate is 4 MHz, having approximately a 50% duty cycle. The oscillator 102 effectively drives a ring counter made up of two D-type flip-flops 108 and 110 which are used for controlling other logic circuits within the clock 100. The clock 100 produces a clock signal -C derived from the flip-flop 110 and additionally produces four basic clock pulses from a ring counter and the oscillator pulses on the phase 1, -phase 1, -phase 1 late, phase 3 late and phase 4 lines, each being nominally 125 ns in duration and having the relationships shown in FIG. 21. More specifically, the flip-flops 108 and 110 are initially in an off state with the flip-flop 110 applying a positive signal to one input of the AND circuit 130 and to condition the flip-flop 108 for being turned on. The leading edge of a pulse from the oscillator 102 is applied via inverters 104 and 106 to turn on the flip-flop 108 which, in being turned on, applies a positive signal to a second input of the AND circuit 130 and to condition the flip-flop 110 for being turned on. At the trailing edge of the first oscillator pulse, a positive signal is applied from the inverter 104 to render the AND circuit 130 effective to apply a positive pulse on the .phi.3L line havig a 125 ns duration. The leading edge of the next oscillator pulse is applied via the inverters 104 and 106 to turn on the conditions flip-flop 110 which, in being turned on, applies a positive signal to condition the AND invert circuit 134 and to turn on the .phi.4 latch 132. The latch 132, in being turned on, applies a positive signal to render the AND invert circuit 134 effective to apply a negative pulse on the -.phi.4 line and, via inverter 136, a positive pulse on the .phi.4 line, both pulses being of 125 ns duration. The flip-flop 110 in being turned on also applies a negative signal to condition the flip-flop 108 for being turned off and to render the AND invert circuit 120 effective to apply a positive signal to the -C line. The leading edge of the next oscillator pulse is effective via the inverters 104 and 106 to turn off the flip-flop 108 which, in being turned off, applies a positive signal to condition the AND invert circuit 124, to turn on the .phi.1 latch 122 and to one input of the AND invert circuit 128 and also applied a negative signal to condition the flip-flop 110 for being turned off. The latch 122 in being turned on applies a positive signal to render the AND invert circuit 124 effective to apply a negative pulse to the .phi.1 line and, via the inverter 126, a positive pulse to the .phi.1 line, both being of 125 ns duration. The flip-flop 110 still being on applies a positive signal to a second input of the AND invert circuit 128. Accordingly, at the trailing edge of the third oscillator pulse, a positive signal is applied from inverter 104 to render the AND invert circuit 128 effective to apply a negative pulse on the .phi.1L line having a duration of 125 ns. The trailing edge of the third oscillator pulse is also effective via the inverter 106 to apply a negative pulse to reset the latch 122. The leading edge of the fourth oscillator pulse is effective, via the inverters 104 and 106, to reset the flip-flop 110 which returns the ring counter back to its initial condition. The flip-flop 110 in being reset applies a positive signal to one input of the AND invert circuit 120 and after a delay provided by the inverters 112, 114, 116 and 118 to render the AND invert circuit 120 effective to apply a negative signal on the -C line. At the end of the fourth oscillator cycle, the clock 100 is back at the initial condition to repeat the generation of the various clock pulses in successive phase times as shown in FIG. 21. Manual Write Master Key (WMK) Operation The write master key operation consists of manually writing 16 half-bytes (4 bits) constituting the master key into the master key (MK) memory via 4 bit lines. Enable write (EW) and manual write (MW) switches are provided to initialize and control the 16 cycles needed for loading the individual half-bytes into the MK memory. Bit switches are also provided for producing the binary coded numbers 0 through F with all outputs being low for 0 and high for F. The master key is pre-generated, in a random manner, as 16 hexadecimal numbers to be written into the 16 locations of the MK memory. The following is a generalized step-by-step procedure of manually writing the master key into the MK memory. Step 1: Set the EW switch to the on or enable write master key (EWMK) position. Step 2: Press the MW switch once to reset the MK memory address counter to 0 and to overwrite the master key presently stored in the MK memory. Step 3: Set the bit switches to the half-byte to be written into the MK memory location 0. Step 4: Press the MW switch once. Step 5: Set the bit switches to the next half-byte to be written into the next succeeding location of the MK memory. Step 6: Press the MW push button once. Steps 7-34: Repeat Steps 5 and 6 in succession until the last half-byte has been written into the last location of the MK memory. Step 35: Set the EW switch to the off position. At any time during the execution of this procedure, as when there is uncertainty that it has been correctly done, a restart can be accomplished by doing Step 35 and beginning again with Step 1. Referring now to FIG. 22c1 and the timing diagram of FIG. 23, a more detailed description of the manual WMK operation will be given in the following. To initiate this operation, the Enable Write (EW) switch, which may be a SPDT switch activated by a physical key lock to prevent the key from being changed by unauthorized persons, is set to the ON position. Following this, the Manual Write (MW) switch, which may be a push-button switch, may be pressed to the MWNO position causing a negative pulse to be applied to turn on the MW latch 138. The latch 138 in being turned on applies a negative signal via the -MW line to turn on the MK BUS SELECT latch 140 and the manual write half byte (MWHB) control latch 154. The latch 140 in being turned on applies a positive signal to condition the AND cir | ||||||