JPH10190649A - Bidirectional data stream transmitting device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To execute a cipher function to the data passing through a protocol stack by ciphering or decoding the data by means of a module or driver which includes a cipher algorithm based on the software or by means of a driver which is connected to a cipher mechanism based on the hardware. SOLUTION: A computer system 100 includes a user space 102 and a kernel space 104. The space 102 includes a user application 106 and a socket 108, and the space 104 includes a stream head 110, a ciphering mechanism module 112, a TCP layer 114, an IP layer 116 and a DLPI layer 118. Then the system 100 calls a copy-in function to move the data to the space 104 from the space 102. The module 112 ciphers the data and both layers 114 and 116 execute the due processing based on a protocol.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

FIELD OF THE INVENTION The present invention relates to data communications within and between computer systems, and more particularly, to computer systems and computers that use a protocol stack that is modified to provide data encryption. -It is related to data communication between systems.

[0002]

BACKGROUND OF THE INVENTION Cryptography is becoming increasingly important in the computer field. The amount of information sent over unprotected networks such as the Internet continues to increase. In addition, unprotected networks are being used not only to perform financial transaction processing, but also to transmit various other types of sensitive personal data.

[0003] Cryptography helps to ensure that data transmitted over an unprotected network is not intercepted by anyone other than the intended recipient. In the prior art, cryptographic functions have usually been controlled by applications that generate encrypted data. Applications use cryptographic algorithms or algorithms stored in a function library otherwise provided by the computer's operating system. This approach has several limitations. First, if a cryptographic algorithm were to be included in the application, updating it would not be easy. Second, the use of cryptographic algorithms stored in a function library (typically a secure socket library) requires that data be copied and processed many times in both user space and kernel space. Is inefficient. Finally, if the application does not support encryption, it is very difficult to encrypt the application's data.

[0004]

Thus, there is a need in computer network technology to shift the cryptographic paradigm from application-based encryption to connection (or input / output) -based encryption.

[0005]

SUMMARY OF THE INVENTION The present invention provides a protocol
A method and apparatus for performing a cryptographic function on data passing through a stack is provided. In the first aspect of the present invention, by using a module or a driver including a software-based cryptographic algorithm, or
Data is encrypted and decrypted by using a driver connected to a hardware-based cryptographic mechanism.

In a second aspect of the invention, a protocol stack multiplexer passes data to a cryptographic module or driver. This embodiment also supports the above-mentioned hardware type configuration and software type configuration. This configuration is particularly beneficial if some of the above hardware-based cryptographic mechanisms are available and the multiplexer is configured to implement a scheduling algorithm that selects available cryptographic functions.

[0007] In a third aspect of the invention, an encryption function is registered at the stream head using dynamic function registration. The encryption function may implement software-based encryption, or may also act as a driver to interface to a hardware-based encryption mechanism. In one configuration of this embodiment, when data is copied from the user space to the kernel space, the data is encrypted, and when the data is copied from the kernel space to the user space, the data is decrypted.

[0008] In a fourth aspect of the invention, data is encrypted and decrypted by a driver or module that includes a dynamically replaceable function that controls the cryptographic process. Also in this embodiment, the above-mentioned hardware type configuration and software type configuration are supported.

Thus, the means provided by the present invention to solve the problems of the present invention include an apparatus disposed in a computer system for transmitting a bidirectional data stream between a device and a user process. . The device comprises:
A device driver connected to the device for transmitting the bidirectional data stream to the device; a bidirectional data stream disposed between the device and the user process between the user process and the device driver; And a cryptographic mechanism for performing an encryption function on the data transmitted in the form of the bidirectional data stream.

[0010]

FIG. 1 is a diagram showing a prior art computer system 10. As shown in FIG. The computer system 10 includes a user space 11 and a kernel space 20.
The user space 11 includes a user application 12, a socket 14, and a secure socket 16. The kernel space 20 includes the encryption mechanism 18, the stream head 2
2, including a Transmission Control Protocol (TCP) layer 24, an Internet Protocol (IP) layer 26, and a Data Link Provider Interface (DLPI) layer 28. The encryption mechanism 18 can be implemented using either a hardware-based encryption algorithm (hereinafter simply referred to as a hardware-based encryption algorithm) or a software-based encryption algorithm (hereinafter simply referred to as a software-based encryption algorithm). it can. Stream head 22, TCP layer 24, IP layer 2
6 and DLPI layer 28 implement a STREAMS-type protocol stack. For details on the STREAMS framework, see "UNlX System V Network Pro" by S.Rago.
gramming "(Addison Wesley professional computing se
ries (1993)), Chapters 3 and 42 starting at page 95
It is described in Chapters 9 to 11 beginning on page 5.

In this specification, the term "encryption" or "encryption" includes not only "encryption" but also "decryption". Therefore, the “encryption key” also includes a key required for decryption. Similarly, the hardware encryption mechanism has a function of decrypting data. Of course, in context, "encryption" may not include "decryption", and such a context will be apparent to those skilled in the art.

As shown in FIG. 1, the user application 12 is configured to transmit and receive encrypted data via a network. To send encrypted data, application 12 must first encrypt the data by sending the unencrypted data to encryption mechanism 18 via secure socket 16. Typically, this is accomplished by the user application 12 calling a system call, such as a send () command. A secure socket library associated with the secure socket 16 maps the send () command to a write command that provides the data to be encrypted to the encryption mechanism 18 (embodiment dependent). After the data has been encrypted, the user application 12 retrieves the encrypted data
Invoke system calls such as the recv () command.
The recv () command is associated with a read command that retrieves the encrypted data from the encryption mechanism 18 (an embodiment-dependent type), and then the encrypted data is passed to the user application 12. The user application 12 is then encrypted by sending the encrypted data via the socket 14 to the stream head 22 by invoking a system call (such as another send () command). Data sent over the network. The encrypted data is sent to stream head 2
2, TCP layer 24, IP layer 26 and DL
It flows to the PI layer 28. DLPI layer 28 provides a DMA between memory and physical network hardware.
Initiate the action and send the encrypted data over the physical network.

Each time a send () or recv () command or an embodiment-dependent read or write command is invoked, data must be moved between user space 11 and kernel space 20. These data movements are accomplished by commands that call either the Unix copyin () or copyout () function. The copyin () function moves data from user space to kernel space,
The pyout () function moves data from kernel space to user space.

[0014] To read the encrypted data, the process is reversed. That is, the DLPI layer 28 performs DMA between physical network hardware and memory.
The operation is started, and the encrypted data is transferred to the IP layer 26,
It flows to TCP layer 24 and stream head 22. User application 12 receives encrypted data from stream head 22 via socket 14 by invoking a system call such as a recv () command. Next, the user application 12 is encrypted by sending the encrypted data to the encryption mechanism 18 via the secure socket 16 by invoking another system call, such as a send () command. Decrypted data and another recv ()
The decrypted data is received from the encryption mechanism 18 via the secure socket 16 by invoking a final system call, such as a command.

While the cryptographic process shown in FIG. 1 is functional, it has several disadvantages. First, processing performance is not optimal. Data is passed in and out of the secure socket 16 and the encryption mechanism 18 and the socket 1
4. Stream head 22 and layers 24, 2
Transfer between 6,28. Such data movement typically requires repeated copying of data between user space and kernel space. In addition, system resources must be occupied to hold multiple sockets, buffers and other resources for each application instance, and the CPU usage as all these tasks are managed. Increase.

Another disadvantage is that the encryption process is controlled from user space 11. Data and activity in user space are less vulnerable to malicious attacks than in kernel space, and therefore, encryption processes controlled from user space are more likely than encryption processes controlled from kernel space. Vulnerable to such attacks. This vulnerability is based on the University of Calif
Eric Brewer, Paul Gauthier, Ian Gol (ornia-Berkely)
Demonstrated by dberg and David Wagner. Brewer et al. Argue that the emphasis on secure session layer protocols and the sufficient randomness of the encryption keys masked the more fundamental flaw in end-to-end security. Specifically, not only must the protocol be secure, but the user code must also be secure at each end point. Brewer and his colleagues have shown how they can change the binary code of a program while it is being transmitted over a network to prove their point. They used that method to change a legal copy of Netscape's navigator browser to a version using a fixed key that only they knew. This is an invisible form of security breach. Thus, even if a user can trust the supplier of a particular application, the code itself is unreliable if transmitted over an unprotected network.

Finally, another disadvantage associated with the cryptographic process shown in FIG.
2 is that encryption must be triggered. If the application 12 is a legacy application that was not designed to support encryption, the data that the application 12 sends over the network cannot be encrypted. Also, even if the user application 12 is designed to support encryption, it may not be flexible enough to support, for example, larger encryption keys or new encryption algorithms that may use different formats.

The present invention solves the problems associated with the cryptographic process shown in FIG. 1 by moving cryptographic functions to the protocol stack. Copying and moving data is minimized by including cryptographic functions in the protocol stack. In addition, since encryption and decryption are performed in kernel space, the cryptographic process is not very vulnerable to malicious attacks or "sniffing". By using the present invention, data can be encrypted using keys provided by the kernel rather than the application. This reduces the role of the user application in performing the encrypted data transmission, which results in increased security. Further, the user application does not need to support encryption. The present invention can be configured to encrypt and decrypt any information passing through the protocol stack.

The present invention supports encryption using either hardware or software encryption algorithms. In the current state of encryption technology, hardware-based cryptographic algorithms are preferred over software-based cryptographic algorithms for several reasons. First, the processing speed of the embedded hardware is high. Currently available encryption hardware has the ability to encrypt data at data rates of 1 megabyte per second or more. Second, since the encryption mechanism is mounted on dedicated hardware, the CPU can be used to execute other processing in parallel. Third, because many hardware-based encryption devices operate as standard SCSI devices, the hardware can be used in unsecured operating systems and on many platforms. Fourth, physical hardware is relatively difficult to modify or interfere. The physical device can also include a mercury destruction device. Finally, updating cryptography is relatively simple. For example, the encryption technology and encryption key can be provided on a PCMCIA card, which can be easily exchanged when updating the encryption technology.

Of course, hardware encryption mechanisms also have various shortcomings, which are now likely to be resolved by software encryption. First, with the number of encryption protocols growing, current hardware encryption embodiments only support up to four encryption protocols. The software can support any number of protocols and can be installed or updated on site. Second, host CPU power tends to be faster than embedded processor power,
Parallel processing and scaling techniques continue to improve.
Eventually, software-based encryption techniques may outperform hardware-based encryption techniques. Third, hardware requires that data be moved through the I / O path or accessed by DMA operations, while software requires the same without requiring DMA operations or hardware interrupt handling. Data can be encrypted within the memory location. In addition, memory bandwidth is typically several times greater than many input / output bandwidths. Fourth, the software does not require multiple context switches and therefore does not pollute the CPU cache. Finally, software can be quickly patched if any security issues are discovered.

The present invention provides maximum flexibility by supporting both hardware and software encryption. Assume that a STREAMS-type protocol stack according to the present invention is configured to perform hardware-based encryption and decryption of all data passing through the stack. When security issues are discovered in hardware-based encryption, software-based encryption algorithms can be exchanged for hardware-based algorithms without affecting applications or users. As security issues are resolved and hardware becomes available, hardware encryption can be easily replaced with a provisional software encryption routine.

Encrypting incoming data and decrypting outgoing data is also within the scope of the present invention, and those skilled in the art will readily know how to adapt the techniques described herein to achieve such a result. Would admit. However, encrypting data in this manner is limited to a very small number of applications, and it is expected that encrypting outgoing data and decrypting incoming data will be more typical. Therefore, an embodiment of the present invention provides a STREAMS TC that encrypts outgoing data and decrypts incoming data.
It is described with reference to the P / IP stack. It should be noted that the techniques described herein can be applied to any type of protocol stack.

FIG. 2 is a diagram of a computer system 100 illustrating an embodiment of the present invention. The computer system 100 includes a user space 102 and a kernel space 1
04. User space 102 includes user application 106 and socket 108. The kernel space 104 includes a stream head 110, an encryption module 112, a TCP layer 114, and an IP layer 11.
6 and DLPI layer 118.

In FIG. 2, when the user application 106 wants to write data over a TCP / IP connection, the application 106 sends the data to the socket 108 by invoking a system call such as a send () command. To send out. System calls transfer data from user space 102 to kernel space 104.
Call the copyin () function to move to. The encryption mechanism module 112 encrypts the data and sends the data to the TCP layer 114.
And the IP layer 116 performs processing according to the TCP / IP protocol, and the DLPI layer 118 initiates a DMA operation to provide data to the physical network hardware. The embodiment shown in FIG.
STR encryption technology using EAMS type module
Add to EAMS type protocol stack. In FIG. 2, the cryptographic module 112 may be located in various other locations besides those shown, such as between the TCP layer 114 and the IP layer 116 or between the IP layer 116 and the DLPI layer 118. It is possible.

The encryption module 112 encrypts data using software-based or hardware-based algorithms that are well known in the art. In addition, the user application 106
Can add or delete an encryption function by putting the encryption mechanism module 112 on the stack or pulling out the encryption mechanism module 112 from the stack. This is because the encryption module 112
Works especially well if is the first module next to the stream head 110 as shown in FIG.

In addition, the computer 100 executes the STRE
AMS can be configured to add cryptographic functionality to any TCP / IP stack using the autopush function. The autopush mechanism allows a module to be automatically pushed onto the stack by the operating system whenever a predefined type of stack is opened. For example, if a properly configured autopush mechanism is provided, the user application
When opening the stack, the encryption module must be
It is placed on the stack at a position after the CP layer 114.

Also, the encryption mechanism module 112
Place it just above PI layer 118 and use a single DLPI
All data passing through the layer instance can also be configured to be encrypted. However, such an arrangement requires some mechanism to distinguish between stacks that encrypt with the DLPI layer and those that do not. One mechanism is to use different device filenames for a single hardware device instance, associate the filename with one in a protocol stack that supports encryption, and use a protocol protocol that does not support encryption. Associate another file name with the stack. Whenever a stream referring to a file name associated with encryption is opened, the encryption mechanism module 112 is automatically pushed to the DLPI layer 118 and the encryption mechanism module 112
The above mechanism works well with the autopush mechanism, as the operating system can be configured to link 116 to the P-layer. in addition,
The utopush mechanism can be configured so that the encryption mechanism module 112 is not pushed to the DLPI layer 118 when a stream that refers to the file name associated with the stack that does not perform encryption is opened.

Also, by using another mechanism for distinguishing between decrypting and non-decoding stacks in the DLPI layer, the ifconfig function is used to specify whether encryption is required when configuring a network connection. be able to. On Unix operating systems, the ifconfig function call is
It can be used to assign addresses to interfaces or to configure network interface parameters. The ifconfig function call must be used at startup to define the network address of each of the interfaces currently on the computer system, and at other times to redefine specific addresses and other operating parameters. Can be used for Thus, the present invention includes a modified ificonfig function call that has the ability to define encryption parameters along with other network interface parameters.

FIG. 3 is a diagram of a computer system 120 illustrating another embodiment of the present invention. Computer system 120 includes a user space 122 and a kernel space 124. User space 122 includes user application 126 and socket 128. The kernel space 124 includes a stream head 130, an encryption multiplexer 132, a TCP layer 134, an IP layer 136, a DLPI layer 138, and an encryption mechanism driver 140. User application 126,
Socket 128, stream head 130, TCP layer 134, IP layer 136 and DLPI layer 1
38 operates similarly to the component with the corresponding name in FIG. However, instead of placing the encryption module in the same row as the other stack modules as in FIG. 2, the encryption multiplexer 132 is configured to transfer data to and from the encryption mechanism driver 140.

A STREAMS-type multiplexer module is a standard STREAMS component used to route data to a destination. For example, multiplexer modules are used by networking protocols to multiplex multiple messages between multiple users and possibly multiple transmission media.
Similarly, cryptographic multiplexer 132 allows a single hardware-based cryptographic mechanism to be shared by multiple STREAMS stack instances simultaneously. Alternatively, cryptographic multiplexer 132
By using a simple scheduling algorithm, it can be configured to select one available hardware-based encryption mechanism from a plurality of hardware-based encryption mechanisms.

In the prior art, a secure socket library (ie, Secured Socket Library, SSL)
Specification v.3.0 defines a protocol that allows a cryptographic package that passes messages to and from a user application to configure cryptographic processing, including cryptographic keys used and encrypted connections. I have. To provide maximum compatibility and minimize programming costs, the present invention takes advantage of this protocol,
The encryption multiplexer 132 of FIG. 3 is used to store the encryption key and direct encryption and decryption. In the embodiment shown in FIG. 2, the encryption mechanism module 112 stores the encryption key and instructs encryption and decryption.

While both embodiments shown in FIGS. 2 and 3 can be configured to use either software-based encryption or hardware-based encryption, the embodiment of FIG. 2 uses the same for software-based encryption. Are more suitable, while the embodiment of FIG. 3 is more suitable for use with hardware-based encryption. The following description describes the cryptographic multiplexer 132 and the cryptographic mechanism driver 140
Will be described, but similar techniques may be used to adapt the encryption mechanism module 112 of FIG. 2 to operate with a hardware encryption mechanism. Will be recognized by those skilled in the art.

When a data message indicating the data to be encrypted arrives at the multiplexer 132, the multiplexer 132 examines the message and looks up the appropriate encryption key. An encryption key may be bound to an application instance in such a way that all data originating from a particular application uses a particular key, or if all data sent to a particular IP address is The encryption key may be bound to the IP address in such a way that it is encrypted using the key. After obtaining the encryption key, the encryption multiplexer 132 obtains a spinlock that is used to automatically increment a "working" counter. This "in progress" counter indicates that the TCP / IP stack has in-progress cryptographic processing and will not close the stream until this counter is equal to zero, indicating that there is no pending cryptographic request. Indicate that you cannot. The “in process” counter is the
2 instances are defined as part of a private data structure associated with each instance. By checking this counter, a close race condition that could lead to a system panic is prevented.

The cryptographic multiplexer 132 then sets up a data structure that includes a callback function (usually a STREAMS putnext () function) that targets the write queue of the next module in the stack (in this case, the TCP layer 134). . The data structure also includes a pointer to a memory block that holds the data to be encrypted. Next, the multiplexer obtains a synchronization queue that serializes the encryption request. The cryptographic multiplexer 132
If the synchronization queue cannot be acquired because another encryption operation is in progress, the multiplexer acquires the hardware wait queue spinlock and places the transaction in the wait queue for future processing. next,
The cryptographic multiplexer 132 returns to processing other messages passing through the stack.

When the synchronization queue is obtained, the hardware-based encryption process is started using a software interrupt service. This software interrupt service allows hardware-based encryption mechanisms to perform cryptographic operations without affecting the execution of user application 126 by executing in parallel with user application 126. After encrypting the data, the hardware-based encryption mechanism provides an interrupt service routine (ie, an interrupt service routine, IS).
Call R). The ISR invokes a callback function,
The callback function sends the encrypted data to the write queue of TCP layer 134 and clears the "in process" flag by acquiring the flag's spinlock. Because the cryptographic hardware performed the encryption directly on the data stored in the memory blocks, the encryption was performed on the fly without unnecessary memory management or data movement.

Although the process is basically the same for incoming data, the only difference is that the encryption multiplexer 13
2 is that the callback function included in the data structure set by 2 has a read queue for stream head 130 as a target. FIGS. 2 and 3 illustrate how cryptographic functions are added to a STREAMS-type protocol stack using standard STREAMS modules and drivers. The techniques described in 08 / 545,561 can also be applied to provide a better mechanism for providing cryptographic functions in a STREAMS-type protocol stack.

Prior art STREAMS type protocol
In a stack, a stream is constructed by putting (ie, pushing) modules into a LIFO (ie, last-in-first-out) stack. (TCP of FIG. 1
When a module (such as layer 24) is pushed onto the stack, the module is linked to the read and write queue of the module or driver (such as IP layer 26) that was previously pushed onto the stack and pushed onto the stack. The read and write queues for the module being
(Like). At the bottom of the stack is a driver such as (DLPI layer 28) that links data to physical hardware or performs processing functions and the like. The stream head is at the top of the stack and copies data between user space and kernel space. The stream head also serves as the entry point to the stream from the point of view of the user application. Modules between the driver and the stream head perform various processing functions.

In the prior art, changing the functionality of a stream required that the stream be separated and reconstructed. If the functionality of a module adjacent to the driver needs to be changed, any modules above the driver must be pulled off the stack, and the updated version of the module (including the new functionality) will be pushed onto the stack. All previously existing modules upstream from the changed module had to be pushed back onto the stack. This process is slow and the processor is busy, and the stack is unavailable during the reconfiguration.

The dynamic function replacement function (ie, dynamic f
unction replacement) allows the module to have an alternative execution path. By issuing the command
During execution, various functions can be switched into and out of the STREAMS-type protocol stack. Dynamic function replacement is an ideal mechanism that gives the TCP / IP stack the ability to selectively perform encryption and decryption of data passing through the stack. In addition, the TCP / IP stack can be configured for multiple cryptographic protocols, which can be changed dynamically as needed.

In contrast, dynamic function registration (ie, dynamic
function registration) allows various functions to be registered with the stream head. The stream head includes a controller having a function of instructing execution of a registered function. One characteristic application for dynamic function registration is 32-bit to 6-bit.
Conversion to 4 bits. When a 32-bit application writes data to a 64-bit operating system stream head, it recognizes that the data needs to be converted to 64-bit format and
The stream head can be configured to direct the modules in the EAMS-type stack to perform the conversion. As the terminology implies, dynamic function registration can be used to register cryptographic functions and to control the execution of those functions on data flowing through the protocol stack. Registration of functions can be done by user process or STR
Initiated by an EAMS type module or driver.

Dynamic function registration allows functionality to be added to or removed from the stream head. In contrast, dynamic function replacement allows adding functionality to any module or driver in the stream by swapping different execution paths to and from the stream head, or Allows you to delete from there.

One embodiment of the present invention encrypts and decrypts data at the stream head 22 of FIG.
Since cryptographic functions are added at the stream head, dynamic function registration is used to control the encryption and decryption of data flowing through the stream. Another embodiment is
At another point in the TCP / IP stack, which is different from the stream stack (eg, between TCP layer 24 and IP layer 26 in FIG. 1), the data is encrypted and decrypted. Because the encryption function is added to the module or driver, configure the module or driver to provide the encryption function, or use dynamic function replacement to selectively select the encryption function in the execution path of the module or driver. Can be inserted.

Each of the hardware and software embodiments described below can be readily adapted by those skilled in the art to apply to known UDP / IP stacks or other protocol stacks.

FIG. 4 is a diagram of a computer system 30 adapted to encrypt and decrypt data passing through a STREAMS type protocol stack in accordance with the present invention. The computer system 30 includes a user space 32
And a kernel space 34. User space 32 includes user application 36 and socket 38.
The kernel space 34 includes a stream head 40, an encryption technology 42, a TCP layer 44, an IP layer 46 and a D layer.
Includes LPI layer 48. The stream head 40 includes a register 50 and a controller 52, and the TCP layer 44 includes a function pointer 54.

The encryption technique 42 is not actually a STREAMS module or driver. Rather, encryption technique 42 is a hardware or software encryption mechanism accessed by a function registered at stream head 40. In the case of a software encryption mechanism, a function registered in the stream head includes an encryption code. For hardware-based encryption,
The function registered in the stream head is a function that has the function of communicating with the encryption driver that interfaces with the physical cryptographic hardware.

STREAM at stream head
To provide cryptographic functions to the S-type protocol stack,
The dynamic function registration is used to control the execution of cryptographic algorithms implemented by the encryption technique 42. Dynamic function registration modifies the standard C library that defines the stream head by adding the public data structures in Table 1 below to the stream head library file <stream.h>.

[0047]

[Table 1] struct sth_func_reg {int (* sth_copyin) (); / * write side copyin * / int sth_copyin_threshold; / * Arguments passed to sth_copyin () * / int (* sth_32_to_64) (); / * write side 32 to 64-bit conversion function * / int (* sth_write_opt) (); / * Write-side option function * / int (* sth_read_opt) (); / * Read-side option function * / int (* sth_ioctl_opt) () / * ioctl option function * / int (* sth_64_to_32) (); / * 64 to 32-bit conversion function on reading side * /}

The present invention modifies the above public data structure by adding: int (* str_copyout) (); / * reader copyout * / The private data structures in Table 2 below have been added to the stream head declaration itself to allow access to public structures.

[0049]

[Table 2] struct sth_s {... struct sth_func_reg sth_f_reg; int32 sth_in_Progress; ...}

Prior art STREAMS type protocol
In a stack, the stream head provides an interface between kernel space and user space, and is a very simple structure. By changing the stream head by dynamic function registration, the stream head stores pointers to various functions,
It is now possible to perform these functions on the data processed by the stream head. The sth_f_reg structure defined above provides a location where pointers to functions are stored. Stream head sth_f_
If the reg structure contains a pointer to a function, that function will be executed when the data is processed by the stream head.

With the exception of the copyin and copyout functions, s
All of the function entries defined in the th_f_reg structure execute optional functions. In other words, if the corresponding entry in the sth_f_reg structure does not contain a function pointer, the function will not be executed. In contrast, the copyin and copyout functions are alternative functions. If there is no entry for copyin, the default Unix copyin routine is called to copy data between user space and kernel space. Similarly, if there is no entry for copyout, the default Unix copyout routine is called to copy data between user space and kernel space.

The encryption on the write side is performed by either the alternative function sth_copyin or the optional function sth_write_opt, depending on the embodiment of the encryption technique 42.
Similarly, the encryption on the read side is based on the alternative function sth_copyout
Or by one of the optional functions sth_read_opt.

The alternative functions sth_copyin and sth_copyout are very suitable for software-based encryption, where
The encryption technique 42 is implemented by incorporating a cryptographic algorithm into sth_copyin and sth_copyout. Using these functions, data must be encrypted when copied from user space 32 to kernel space 34 and decrypted when copied from kernel space 34 to user space 32, thereby handling the data. The number of times is kept to a minimum. Checksum functionality is copyin
Sth_copyin_thresho
ld continuously reflects the TCP MTU size, as disclosed in US patent application Ser. No. 08 / 593,313.

Optional functions sth_read_opt and sth_wr
ite_opt can be used with either software-based cryptographic algorithms or hardware-based cryptographic algorithms, and offers several advantages. First, st
h_write_opt can be called on the encapsulated data. One way to form encapsulated data is to call the esballoc () system call. The esballoc () system call is
As is known in AMS programming techniques, fetch memory of any size in kernel space and b_da
Allocate an mblk header pointing to this memory via tap and b_rptr pointers. For example, if you want to encrypt the data stored in the buffer cache and transmit the data over the network, esballoc ()
System calls are invoked on data in the cache. The copyin function is not required because the encapsulated memory already exists in kernel space. Therefore, the copyin / encrypt combination function cannot be executed on the data, but sth_write_
opt can encrypt data already in the kernel.

The second advantage is that sth_write_opt and d sth
_read_opt is called when the entire mblk chain is available, so that the cryptographic algorithm can use the individual mblk type to indicate how the chain should be encrypted. In contrast, sth_copyin does not access the entire mblk chain until all data has been copied to kernel space 34 and encrypted. For example, consider an mblk chain that includes one M_PROTO message followed by one or more M_DATA messages. In this case, the M_PROTO message contains a data structure that describes how the data is encrypted. Such a data structure may include an encryption technology identifier, a public encryption key, an identification server identifier, and other information for controlling the encryption process. Using this method, the encryption technique can be changed on a message-by-message basis, or at arbitrary intervals, thereby avoiding cryptographic typology.

When the encryption technology 42 uses a hardware-type encryption mechanism, a driver capable of driving the hardware-type encryption mechanism uses sth_write_opt and sth_rea.
It is registered in the stream head 40 as a d_opt function. As in the embodiment shown in FIG. 3, the hardware encryption mechanism must be monitored for a close race condition. However, as described above, in FIG. 3, a close race condition is detected by an "in process" counter that is modified and checked in the encryption multiplexer 132. Therefore, the cl associated with the encryption multiplexer 132
The ose () routine has access to a "working" counter. The situation is somewhat different in the embodiment shown in FIG. Since the stream head 40 controls a driver that encrypts and decrypts data, sth_in_progres
The s counter is defined as a part of the stream head 40 private data structure, and sth_in_progress
The stream cannot be closed unless the counter reaches zero. Thus, to allow the close () function of the various modules and drivers in the stack to access the "in process" counter, and to allow the register function to increment and decrement the counter
The STREAMS kernel interface is required. The various forms of such interfaces are
Included in the Unix version. Transmission independent STRE
The AMS kernel interface has been included since Hewlett-Packard's version of Unix release 10.10, but will be officially provided to developers by release 10.30.

The close () routine of all modules and drivers adjacent to the level at which encryption is being performed has been modified to check the "in progress" counter before allowing the respective module or driver to be closed. There must be. The close () routine can be implemented by modifying the code of the module in a manner well known to those skilled in the art, or by defining an alternate execution path using the techniques disclosed in U.S. patent application Ser. No. 08 / 545,561. Can be changed.

The following program code (from Table 3) shows how to modify the close () routine to support a hardware encryption mechanism. The close () routine must be modified to include the following code:

[0059]

[Table 3] do {spinlock (sth-> sth_in_progress_flag_lock); if (sth-> sth_in_progress) {/ * There is a cryptographic process in progress * / get_sleep_10ck ((int) & sth-> sth_in_progress_sleep_addr); spinunlock (sth-> sth_in_progress_flag_lock); error = sleep (& sth-> sleep (& sth-> sth_in_progress_sleep_addr); if (error) error = EINTR;}} while (error == 0);

The above loop allows the close () routine to pause without causing a system panic or deadlock. Threads cannot exist until the current thread used to support the cryptographic hardware performs the following operations (Table 4).

[0061]

[Table 4] spinlock (sth-> sth_in_progress_flag_lock); sth-> sth_in_progress ++; spinunlock (sth-> sth_in_progress_flag_lock); / * Execute processing * / / * Reset flags and start all sleeping threads * / spinlock (sth-> sth_in_progress_flag_lock); sth-> sth_in_progress--; spinunlock (sth-> sth_in_progress_flag_lock); wake up (& sth-> sth_in_progress_sleep_addr);

When sth_write_opt and sth_read_opt are registered in the register 50 of the stream head 40, the controller 52 executes sth_write_opt to encrypt outgoing data, and executes sth_read_opt to decrypt incoming data. The encryption technique 42 is implemented as a hardware encryption mechanism, and the user application
When writing data via sth_write_opt, the sth_write_opt first accesses the spinlock and increments the "working" counter. As described above, this flag is
It must be set using the MS kernel interface and the close () operation must wait if the counter is not zero.

Next, the hardware synchronization queue of the hardware encryption mechanism must be obtained by sth_write_opt. Unlike the encryption multiplexer 132 (of FIG. 3), which cannot wait for the synchronization queue because it must be serviced, sth_write_opt pauses until hardware becomes available. sth_writ
When e_opt gets the synchronization queue, sth_write_opt returns mb
Pass the lk data address to the hardware encryption mechanism and call the hardware encryption routine. At some point thereafter, the hardware encryption mechanism returns the encrypted data, sth_write_opt decrements the "working" counter, and the routine ends. Next, the STREAMS framework passes the mblk data address to the TCP layer 44 and processing continues.

When the encryption technique 42 is implemented as a hardware-type encryption mechanism, and a user application reads data via the socket 38, sth_read_opt first accesses the spinlock (spinlock) and reads the "processing" counter. Is incremented. Next, the hardware synchronization queue of the hardware encryption mechanism must be obtained by sth_read_opt. When sth_read_opt gets the synchronization queue, sth_read_opt passes the mblk data address to the hardware encryption mechanism and calls the hardware encryption routine. At some point thereafter, the hardware encryption mechanism returns the decrypted data and sth_read_opt
Decrements the "in process" counter and the routine ends. Next, the STREAMS framework uses the user space 122
Completes the transfer of data to, thereby completing the read operation requested by the user application 126.

If the module or driver is str_func_ins
You can register a function with the stream head by executing a function called tall,
It is described in US patent application Ser. No. 08 / 593,313 that the function pointer of the function identified by the module or driver can be sent to an entry in the sth_f_reg data structure. For example, in FIG.
Registers one encryption function by calling str_func_install and transmits the function pointer stored in function pointer table 54 to the appropriate entry in the sth_f_reg data structure. The function pointer transmitted in this case is represented by a register 50 in the stream head.

The present invention provides two STREAMS ioctls.
Add commands. These commands allow the user application 36 to configure encryption,
It is also useful in other dynamic function registration applications. ioctl command I_GET_FUNC_REG
Is transferred by the application 36 via the stream head 40 to each of the drivers and modules in the protocol stack. Each of the drivers and modules in the stack returns a function registration list containing the name and unique identifier for each of the possible functions, so that the user application 36 is notified of the presence of all functions that can be registered. . Using this information, the user application 36 can issue a second ioctl command I_SET_FUNC_REG. This command allows the user to register a function in the same way that a module or driver can execute the str_func_install function or register an M_SETOPTS message by sending the M_SETOPTS message, as described in U.S. patent application Ser. No. 08 / 593,313. Enable the application 36 to register functions.

In another configuration, the above ioctl
A thread that has a security feature that uses is executed.
This thread can automatically register the appropriate encryption function based on the application or environment.
This configuration is particularly beneficial when used for applications that are not designed to support encryption. The thread having the security function may be configured to cooperate with an authentication server that provides an encryption method and an encryption key based on a user login, an application, a destination IP address or other characteristics. One such thread is Kerberos
It may be configured to operate in cooperation with a well-known authentication server such as an authentication system.

A more sophisticated method of function registration involves modifying the TCP layer 44 to filter messages, register functions and configure message-based encryption. Modification of TCP layer 44 can be performed by modifying the module code in a well-known manner, or by defining a replacement function according to US patent application Ser. No. 08 / 545,561. For example, TPI T_CO
A replacement TCP module write function put can be defined that checks for messages such as NN_REQ and T_BIND_REQ messages. For example, a TPI T_CONN_REQ message is used to establish a connection to a specific IP address. The replacement put function can be configured to check the IP address and determine (by accessing the encryption server or other means) whether the IP address is secure and remote. No encryption is required if it is secure. Otherwise, the replacement put routine can register the appropriate cryptographic function. Further, the replacement put routine can supply the encryption key or obtain the key from another source, such as a cryptographic server.

The replacement put routine is T_BIND_RE of TPI.
It can be built to look at Q messages. T
The PI's T_BIND_REQ message is used to bind the application to the specified protocol stack and port. Replace put in the same way as above
The function can determine what level of encryption is needed, determine the encryption key, and register the encryption function with the stream head. Such replacement put functions are particularly beneficial when used in connection with applications that were not originally designed to use encryption.

Although the above description is for the TCP / IP stack, it should be noted that similar techniques can be used for other protocol stacks. Further, for certain types of protocol stacks, such as UDP / IP stacks, simpler techniques can be used. In most embodiments, UDP is a connectionless datagram protocol. In FIG. 4, the TCP / IP protocol stack provides a UDP by replacing TCP layer 44 with a UDP layer.
/ IP protocol stack.
UDP message is T_UN followed by M_DATA message
It consists of an M_PROTO message containing an ITDATA_REQ message. Since the T_UNITDATA_REQ message includes the IP address, the registered function can simply perform encryption on a message-by-message basis as needed.

FIG. 5 illustrates a computer system 150 for encrypting and decrypting data in accordance with another embodiment of the present invention. Computer system 1
50 includes a user space 152 and a kernel space 154. User space 152 includes user application 156 and socket 158, and kernel space 15
4 is a stream head 160, a TCP layer 16
2, including an IP layer 164, a DLPI layer 166, and an encryption technique 168.

In FIG. 5, IP layers 164 and D
The put routine of LPI layer 166 has been modified to pass data to and from encryption technology 168. However, the encryption technology 168 is based on TCP / IP
It is also possible to place it elsewhere in the stack. The put routine can be modified using techniques well known to those skilled in the art, or the replacement put routine can be implemented using the dynamic function replacement disclosed in U.S. patent application Ser. No. 08 / 545,561. It can also be inserted into the path. If a software cryptographic algorithm is used, the algorithm can be directly replaced and included in the put routine.

FIG. 6 is a detailed diagram of the IP layer 164, the DLPI layer 166, and the encryption driver 168. FIG. 6 illustrates an embodiment configured to encrypt data using a hardware-based encryption mechanism. FIG.
In, the write-side put routine of the DLPI layer 166 has been replaced with a replacement put routine that sends output data to the encryption driver 168. After being encrypted, the data is placed on the DLPI layer 166 write queue by the encryption driver 168. IP layer 1
The 64 read put routines have also been replaced with replacement put routines that send incoming data to the encryption driver 168. After being decoded, the data is placed in a read queue of the IP layer 164.

The problems associated with adding hardware-based encryption to the protocol stack are similar to those associated with the embodiments described above. Therefore, the encryption driver 1
68 includes a "working" counter, a synchronization queue, and a register that stores the mblk address of the memory block being processed.

In order to add encryption to computer system 150 using dynamic function replacement, replacement put and close routines for IP layer 164 and DLPI layer 166 must be defined. Dynamic function replacement is a standard Unix System V Release
e 4.2 (SVR4.2) STREA of Device Driver Reference
Uses MS data structure. The data structures modified to implement dynamic function replacement are streamtab and qinit.
Structure. Each module or driver defines a streamtab structure that contains a pointer to a qinit structure.

The qinit structure is for a read, write, write multiplexer and a multiplexer queue created by the STREAMS framework. The qinit structure contains function addresses for open, close, put, service, and administrative functions called by the STREAMS framework on behalf of the queue owner, such as a module or driver.

The functions defined within the qinit structure are actually written by the module or driver developer and are automatically executed by the framework based on the current application execution path, such as messages traversing the stream. . If the STREAMS framework knows the location of all of these data structures,
Dynamic function replacement remaps these structure addresses to alternative streamtabs and qinit structures that define new function addresses, as they may access them independently of the application, module or driver. Table 5 below is the basic STREAMS framework data structure.

[0078]

Table 5 / * STREAMS queue initialization structure * / struct qinit {int (* qi_putp) (); / * queue put procedure * / int (* qi_srvp) (); / * queue service procedure * / int (* qi_qopen) (); / * queue open procedure * / int (* qiqclose) (); / * queue close procedure * / int (* qi_qadmin) (); / * queue administrative procedure * / struct module_info * qi_minfo; struct module_stat * qi_mstat:}; / * STREAMS driver and module declaration structure * / struct streamtab {struct qinit * st_rdinit; / * Read queue definition * / struct qinit * st_wrinit; / * Write queue definition * / struct qinit * st_muxrinit; / * Only for multiplexer driver * / struct qinit * st_muxwinit; / * Same as above * /}

The basic fields in these data structures are standardized by the SVR4.2 Device Driver Reference, commonly called a device driver interface.

Assume that the IP module has the following standard replacement structure (Table 6).

[0081]

[Table 6] / * Standard read side qinit structure * / struct qinit IP_rinit = {IP_rput, IP_rsrv, IP_open, IP_close, NULL, & IP_minfo, NULL} / * Standard write side qinit structure * / struct qinit IP_winit = {IP_wput, IP_wsrv , IP_open, IP_close, NULL, & IP_minfo, NULL} / * Replacement reading side qinit structure * / struct qinit IP_rinit_encrypt = {IP_rput_encrypt, IP_rsrv_encrypt, IP_open, IP_close_encrypt, NULL, & IP_minfo, NULL} / * Replacement writing side qinit structure * / struct qinit IP_winit_encrypt = {IP_wput_encrypt, IP_wsrv_encrypt, IP_open, IP_close_encrypt, NULL, & IP_info, NULL} / * Standard streamtab * / struct streamtab IP = {& IP_rinit, &IP_winit}; / * Replace (encrypt) streamtab * / struct streamtab IP_encrypt = _ , &IP_rinit_encrypt};

Dynamic Function Replacement defines a str_alt_install () routine that constitutes alternative streamtabs for STREAMS modules and drivers. Alternative streamt
abs can be dynamically swapped with the stream's execution path using a STREAMS ioctl call. The str_alt_install () routine is called by the following call (Table 7).

[0083]

[Table 7] str_alt_install (name, flags, n, streamtabs) where char * name; / * module or driver name * / unsigned int flags; / * STR_IS_MODULE / DEVICE * / int n; / * number of alternative streamtabs * / struct streamtab * streamtabs []; / * pointer array to streamtabs * /

The STREAMSioctl command available to user application 156 is I_ALTSTRT
AB_ACTIVE and I_ALTSTRTAB_FUTURE. I_ALTSTR
TAB_ACTIVE is the active stream of the module instance
tab, while I_ALTSTRTAB_FUTURE selects the active streamtab for the module type when a future instance of that module type is opened.

In addition to the replacement functions defined for IP layer 164, the replacement functions for DLPI layer 166 must be defined in a similar manner. Once the replacement function is defined, the user application 156 enables the encryption function by invoking the "encryption" streamtabs and "default" stre
Remove the encryption function by starting amtabs.
In another configuration, the cryptographic module is STREAMS
Pushed onto the type protocol stack. in this case,
The cryptographic module has the usual functions of passing data and being active when encryption is not required, and has a cryptographic replacement function used when encryption is required.

Secured Socket Library (SSL) Specification v.3.0
Prior art cryptographic packages such as serve several purposes. Such packages determine the encryption technology to be used, determine the public and private encryption keys to be used, and exchange data with the encryption technology. The present invention incorporates these features and offers several new advantages. For example, a single common interface used for both network communication and encryption techniques is used, thereby simplifying user applications. Cryptographic packages no longer have a responsibility to coordinate the movement of data with the cryptographic technology. This is now handled by the STREAMS framework.

In addition, the present invention improves processing performance and throughput. The data need only pass through the protection zone between user space and kernel space only once, thereby reducing the number of required context switches. The present invention also reduces system resource utilization as compared to prior art cryptographic packages. SSL
Means multiple sockets, buffers, file tables,
Requires entries, etc. In contrast, because existing protocol stacks can be used to support cryptography, only the additional resources required to exchange data with encryption techniques are needed to implement the present invention. Is all.

The present invention also provides a more basic system
Provide cryptographic functions at the level. Using the present invention, a computer system can be configured to implement a unified system-level cryptographic strategy. For example, TC
All data passing through P / IP can be encrypted independently of any user applications that may use the TCP / IP stack. This improves security because encryption control can be removed from multiple application developers and given to a single system developer. Also,
Because encryption and decryption are performed in kernel space, the system is more secure and less likely to be attacked by user applications. Finally, Unix standard STRE
Since the AMS interface is used, continuous improvement and updating of the cryptographic package can be performed while maintaining seamless integration and updating with the user application.

Although the present invention has been described with reference to specific preferred embodiments, workers skilled in the art will recognize that changes may be made in form and detail of the invention without departing from the spirit and scope of the invention. Will be.

The present invention includes the following embodiments as examples. (1) An apparatus disposed in a computer system for transmitting a bidirectional data stream between a device and a user process, the device being connected to the device and transmitting the bidirectional data stream to the device. A driver, a stream head disposed between the device and the user process for transmitting the bidirectional data stream between the user process and the device driver, and in the form of the bidirectional data stream. An encryption mechanism for performing an encryption function on the data to be transmitted. (2) The bidirectional data stream transmission device according to (1), wherein the stream head includes a function controller that controls the encryption mechanism. (3) the encryption mechanism comprises an encryption function identified by a function pointer, the stream head including an activity function register configured to receive a function pointer identifying the encryption function; The bidirectional data stream transmission device according to (2), wherein an encryption function controller controls execution of the encryption function identified by a function pointer stored in the activity function register. (4) The bidirectional data stream transmission device according to (3), wherein the device driver includes an available function register that stores the function pointer that identifies an encryption function.

(5) The bidirectional communication according to (4), wherein the device driver starts an operation of transmitting the function pointer stored in the available function register to the activity function register of the stream head. Data stream transmission device. (6) The device driver is configured to receive from the user process a command instructing the user process to check the function pointer stored in the available function register of the device driver. The bidirectional data stream transmission device according to (5), wherein: (7) (3) wherein the stream head is configured to receive a command confirming the function pointer from a user process and store the function pointer in the active function register of the stream head.
2. The bidirectional data stream transmission device according to claim 1. (8) The bidirectional data stream transmission device according to (3), wherein the computer system is configured to execute a thread for confirming the usable encryption function to the user process. (9) The user and the user are required to confirm an encryption function selected from the available encryption functions to the thread.
The bidirectional data stream of claim 8, wherein a process is configured and the thread is configured to store a function pointer identifying an encryption function selected from among the stream head activity function registers. Transmission equipment.

(10) The user process exists in the user space, the device driver exists in the kernel space, the encryption mechanism has a combination function of encryption and copyin, and data is stored in the user space. The bidirectional data stream transmission device of (2), wherein the function controller controls encryption of the bidirectional data stream by executing the combination function when copied between the kernel spaces. (11) the device driver is in a kernel space, the bidirectional data stream includes a data block existing in the kernel space, and the encryption mechanism performs the above operation on the data block existing in the kernel space. The bidirectional data stream transmission device according to the above (2), which performs an encryption function. (12) 1 data block exists in the kernel space
The bidirectional data stream transmission device according to (11), wherein the transmission device is identified by one M_PROTO message and at least one M_DATA message. (13) The bidirectional data stream transmission device according to (12), wherein the M_PROTO message identifies an encryption algorithm to be used by the encryption mechanism when encrypting data included in the data block. (14) The bidirectional communication according to (12), wherein the M_PROTO message identifies an encryption key to be used by the encryption mechanism when performing the encryption function on data included in the data block. Data stream transmission device. (15) the M_PROTO message identifies an authentication server, and the authentication server identifies an encryption key to be used by the encryption mechanism when performing the encryption function on the data contained in the data block; The above (1
The bidirectional data stream transmission device according to 2).

(16) The encryption mechanism includes a software function, and the device driver and the stream
The bidirectional data stream transmission device according to (1), further comprising a module connected between the heads for transmitting a bidirectional data stream between the two and transmitting the bidirectional data stream to the encryption mechanism. (17) an encryption driver, wherein the encryption mechanism includes a hardware encryption device, connected to the hardware encryption device, and controlling the hardware encryption device to execute an encryption function on the bidirectional data stream; The device driver and the stream
A module disposed between the heads and connected to the encryption driver for transmitting the bidirectional data stream between the device driver and the stream head and sending the bidirectional data stream to the encryption mechanism; The bidirectional data stream transmission device according to (1), further comprising: (18) The bidirectional data stream is subdivided into a plurality of memory blocks, a reference count is initialized to a start value, and the reference count is determined by a first memory block of the plurality of memory blocks. Incremented when sent to the encryption driver and the reference count is decremented when the second memory block of the plurality of memory blocks is sent from the encryption driver, unless the reference count is equal to the starting value. The bidirectional data stream transmission device according to (17), wherein the module is not closed.

(19) The bidirectional data stream has an unencrypted part and an encrypted part, and the input / output device is connected to a device driver existing in the kernel space.
In a computer system wherein a user process is configured to be connected to a stream head providing an interface between kernel space and user space, the bi-directional data stream is transmitted between the user process and the input / output device. Communicating an unencrypted portion of the bidirectional data stream between the user space and the kernel space; Executing an encryption function that moves data between the unencrypted portion of the bidirectional data stream and the encrypted portion of the bidirectional data stream; Communicating to the device driver; and the bidirectional data stream. Cryptographic function execution method comprising the steps of communicating with the input and output devices the already encrypted part from the device driver. (20) the step of executing an encryption function that moves data between the unencrypted portion of the bidirectional data stream and the encrypted portion of the bidirectional data stream, the activity function of the stream head; Sub-step of identifying an active encryption function based on a function pointer stored in a register; and transmitting data between the unencrypted portion of the bidirectional data stream and the encrypted portion of the bidirectional data stream. Performing the activity encryption function to move.
A method for executing a cryptographic function according to 9).

(21) identifying an available encryption function based on a function pointer stored in the available function register of the device driver; and storing the available function register of the device driver in the available function register of the device driver. Transmitting the function pointer stored in the available function register to make the available encryption function an active encryption function. (22) transmitting a function pointer identifying an available function from the user process to the active function register of the stream head to make the available encryption function an active encryption function. The cryptographic function execution method according to (20). (23) executing a thread that identifies an available encryption function to a user process; and selecting one encryption function from the available encryption functions.
Sending a function pointer identifying the selected encryption function to an activity function register of the stream head, making the selected encryption function an active encryption function;
The cryptographic function execution method according to (20), further comprising: (24) communicating the unencrypted portion of the bidirectional data stream between the user space and the kernel space; and the encrypted portion of the bidirectional data stream and the unencrypted portion of the bidirectional data stream. Executing an encryption function to move data between encrypted portions, both reading an unencrypted portion of the bidirectional data stream from user space, encrypting the unencrypted portion, and encrypting the unencrypted portion of the bidirectional data stream. (1) moving to the encrypted portion and executing a combined encryption / copyin function that stores the unencrypted portion of the bidirectional data stream in the kernel space.
A method for executing a cryptographic function according to 9).

(25) The unencrypted part of the bidirectional data stream is the unencrypted data that exists in the kernel space.
Block, wherein the unencrypted data block is 1
Performing an encryption function, identified by one M_PROTO message and at least one M_DATA message, for moving data between the unencrypted portion of the bidirectional data stream and the encrypted portion of the bidirectional data stream. The method of claim 19, wherein the step includes sub-encrypting an unencrypted data block that is part of the encrypted portion of the bidirectional data stream into an encrypted data block. . (26) The method according to (25), further comprising identifying an encryption algorithm to be used to encrypt the unencrypted data block based on the M_PROTO message. (27) The cryptographic function execution method according to (25), further comprising a step of identifying an encryption key to be used for encrypting the unencrypted data block based on the M_PROTO message. (28) further comprising: identifying an authentication server based on the M_PROTO message; and identifying an encryption key to be used to encrypt the unencrypted data block based on the authentication server. 25) The cryptographic function execution method according to 25).

(29) An input / output device is connected to a device driver existing in the kernel space, and a user process is connected to a stream head for providing an interface between the kernel space and the user space. A method of encrypting an unencrypted data stream into an encrypted stream when the data stream passes between the user process and the input / output device, comprising: Reading the encrypted data stream; encrypting the unencrypted data stream into an encrypted data stream; storing the encrypted data stream in the kernel space;
A method comprising: sending the encrypted data stream to a device driver; and sending the encrypted data stream from the device driver to the input / output device.

(30) An input / output device is connected to a device driver existing in the kernel space, a user process is connected to a stream head providing an interface between the kernel space and the user space, and a module is connected to the stream head. A computer system configured to provide an interface between the head and the user space, wherein an unencrypted data stream is encrypted as the data stream passes between the user process and the input / output device; Transmitting an unencrypted data stream from a user process in user space to a stream head in kernel space; and transmitting the unencrypted data stream from the stream head to the module. Transmitting; passing the unencrypted data stream to an encryption function; receiving an encrypted data stream from the encryption function; and transmitting the encrypted data stream to the device driver And transmitting the encrypted data stream from the device driver to the input / output device. (31) The unencrypted data stream is subdivided into a plurality of unencrypted memory blocks, and the encrypted data stream is subdivided into a corresponding plurality of encrypted data blocks. Initializing a reference count to a starting value; incrementing the reference count when an unencrypted memory block of the plurality of unencrypted memory blocks is passed to the encryption function; Decrementing the reference count when one encrypted memory block of the plurality of encrypted memory blocks is received from the encryption function; and deactivating the module unless the reference count is equal to the starting value. Prohibiting the closing operation. (32) A method for adding an encryption function to a protocol stack in a computer system, the method including the step of identifying the encryption function, and the encryption function passing through the protocol stack in a first direction. Registering the encryption function with a stream head to enable encrypting data and decrypting data passing through the protocol stack in a second direction.

(33) A data structure for providing a bidirectional data path between a user process, a module, and a device driver in a computer system, wherein the device driver is resident in a system kernel. And the device that transfers data between the device and the device, data written by the user process flows from the device driver in the device direction, and data received by the driver is transmitted from the device to the device so that the data is received by the user process. A data structure configured to flow in the direction of a device driver and comprising a normal function, an encryption function, and means for replacing the normal function with the encryption function. (34) The data structure according to (33), wherein the normal function is a data transfer function.

(35) A program storage medium holding computer readable program code having a function of encrypting and decrypting an interactive data stream when the interactive data stream flows between a device and a user process, A computer readable program for causing a device driver connected to the device to transfer the bidirectional data stream to the device;
Computer-readable means for causing a first segment of code and a stream head connected between the device and the user process to transfer the bidirectional data stream between the user process and the device driver. A second segment of the enabled program code and an encryption mechanism encrypts data passing through the bidirectional data stream in a first direction and decrypts data passing through the bidirectional data stream in a second direction. And a third segment of computer readable program code.

(36) A computer-readable storage medium including an instruction program to be executed by a computer to execute an encryption function on a bidirectional data stream having an unencrypted part and an encrypted part, A data stream flows between a user process and an input / output device, the input / output device is connected to a device driver residing in kernel space, and the user process provides an interface between the kernel space and user space. Wherein the instruction program is configured to be coupled to a stream head, the instruction program transmitting an unencrypted portion of the bidirectional data stream from the user space to the kernel space, performing an encryption function; From the unencrypted part of the bidirectional data stream Moving data to an encrypted portion of the data stream, transmitting the encrypted portion of the bidirectional data stream to the input / output device, and transferring the encrypted portion of the bidirectional data stream to the input / output device Computer readable storage medium comprising transmitting from a computer.

[0102]

In accordance with the present invention, copying and moving data is minimized by including cryptographic functions in the protocol stack. Also, since encryption and decryption are performed in kernel space, the protection of the cryptographic process against malicious attacks is enhanced compared to the prior art in which control is performed in user space. Further, by using the present invention, data is encrypted using a key provided by the kernel rather than the application. This reduces the role of the user application in performing the encrypted data transmission, which results in increased security. Furthermore, since the present invention can be configured to encrypt and decrypt any information passing through the protocol stack, there is no need for the user application to support encryption.

[Brief description of the drawings]

FIG. 1 is a block diagram of a prior art computer system having a prior art protocol stack and a prior art secure socket layer cryptographic package.

FIG. 2 is a block diagram illustrating one embodiment of a computer system in accordance with the present invention that controls data encryption and decryption using STREAMS-type modules and drivers.

FIG. 3 is a block diagram illustrating one embodiment of a computer system according to the present invention for transmitting data to an encryption module or driver using a STREAMS-type encryption multiplexer.

FIG. 4 is a block diagram of a computer system in which an encryption technique is controlled by a function registered in a stream head.

FIG. 5 shows a computer according to the invention in which encryption technology is inserted between the layers of the protocol stack.
FIG. 1 is a block diagram illustrating one embodiment of a system.

6 is an IP of the computer system shown in FIG.
FIG. 3 is a block diagram showing an encryption driver inserted between a layer and a DLPI layer.

[Explanation of symbols]

10, 30, 100, 120, 150 Computer system 11, 32, 102, 122, 152 User space 12, 36, 106, 126, 156 User application 14, 38, 108, 128, 158 socket 16 Security socket 18 , 112 encryption mechanism
(Module) 20, 34, 104, 124, 154 Kernel space 22, 40, 110, 130, 160 streams
Heads 24, 44, 114, 134, 162 TCP 26, 46, 116, 136, 164 IP 28, 48, 118, 138, 166 DLPI 42, 168 Encryption technology 50 Register 52 Controller 54 Function pointer 132 Encryption multiplexer 140 Encryption Driver

Claims (1)

[Claims] 1. An apparatus disposed within a computer system for transmitting a bidirectional data stream between a device and a user process, the apparatus being connected to the device and transmitting the bidirectional data stream to the device. A device driver, located between the device and the user process,
A stream head for transmitting the bidirectional data stream between the user process and the device driver; an encryption mechanism for performing an encryption function on data transmitted in the form of the bidirectional data stream; A bidirectional data stream transmission device comprising: