Secure packet processor

Details Secure packet processor Secure packet processor

1999-06-30

2004-04-20

Darrow, Justin T. (Department: 2132)

Electrical computers and digital processing systems: support

Multiple computer communication using cryptography

Packet header designating cryptographically protected data

C713S176000, C713S179000

Reexamination Certificate

active

06725371

ABSTRACT:

BACKGROUND
The invention relates to a secure packet processor.
Referring to
FIG. 1
, a server
12
may communicate with a client
10
by transmitting frames, or packets
8
, of information over a network
18
pursuant to a network protocol. As an example, the network protocol may be a Transmission Control Protocol/Internet Protocol (TCP/IP), and as a result, the client
10
and server
12
may implement protocol stacks, such as TCP/IP stacks
17
and
19
, respectively. For the client
10
(as an example), the TCP/IP stack
17
conceptually divides the client's software and hardware protocol functions into five hierarchical layers
16
(listed in hierarchical order): an application layer
16
a
(the highest layer), a transport layer
16
b
, a network layer
16
c
, a data link layer
16
d
and a physical layer
16
e
(the lowest layer).
More particularly, the physical layer
16
e
typically includes hardware (a network controller, for example) that establishes physical communication with the network
18
by generating and receiving signals (on a network wire
9
) that indicate the bits that make up the packets
8
. The physical layer
16
e
recognizes bits and does not recognize packets, as the data link layer
16
d
performs this function. In this manner, the data link layer
16
d
typically is both a software and hardware layer that may, for transmission purposes, cause the client
10
to package the data to be transmitted into the packets
8
. For purposes of receiving packets
8
, the data link layer
16
d
may, as another example, cause the client
10
to determine the integrity of the incoming packets
8
by determining if the incoming packets
8
generally conform to predefined formats and if the data of the packets comply with cyclic redundancy check (CRC) codes or other error correction codes of the packets. The data link layer
16
d
may also perform address filtering.
The network layer
16
c
typically is a software layer that is responsible for routing the packets
8
over the network
18
. In this manner, the network layer
16
c
typically causes the client
10
to assign and decode Internet Protocol (IP) addresses that identify entities that are coupled to the network
18
, such as the client
10
and the server
12
. The transport layer
16
b
typically is a software layer that is responsible for such things as reliable data transfer between two endpoints and may use sequencing, error control and general flow control of the packets
8
to achieve it. The transport layer
16
b
may cause the client
10
to implement a specific protocol, such as the TCP protocol or a User Datagram Protocol (UDP), as examples. The application layer
16
a
typically includes network applications that, upon execution, cause the client
10
to generate and receive the data of the packets
8
. Quite often, the packets may be secure packets (Internet Protocol Security (IPSec) packets, as examples) that have security features that may delay processing of the packets by network devices, such as the client
10
and the server
12
. The IPSec standard is discussed in Request for Comment (RFC) 2401, entitled “Security Architecture for the Internet Protocol,” dated November 1998. Requests for comments (RFCs) are available at several sites on the Internet.
As an example of the processing that is associated with secure packets,
FIG. 2
depicts the conversion of an unsecure packet
30
into a secure packet
37
. In particular, the client
10
, for example, may use a two stage process to add security features to the packet
30
. In this manner, the client
10
may first encrypt an unencrypted portion (called plaintext
32
) of the packet
30
to produce an intermediate packet
36
that includes ciphertext
34
, the encrypted version of the plaintext
32
. Next, the client
10
may process the intermediate packet
36
to produce the secure packet
37
that includes an authentication signature
39
and the ciphertext
34
. Secure packets that the client
10
receives from the network
18
may also be processed in a similar manner that first includes authenticating the received packet and then decrypting the ciphertext of the received packet. Unfortunately, the above-described processing contributes to the latency times that are introduced by converting between secure and unsecure packets.
Thus, there is a continuing need to address one or more of the problems stated above.
SUMMARY
In one embodiment of the invention, a method usable with a computer system includes receiving a packet that includes encrypted data and indicates an authentication signature. The encrypted data is decrypted to produce second data, and the encrypted data is used to validate the signature concurrently with the decryption of at least a portion of the encrypted data.
In another embodiment, a method usable with a computer system includes receiving a packet that includes first data. The first data is encrypted to produce encrypted data. The encrypted data is used to form an authentication signature concurrently with the encryption of at least a portion of the first data.


REFERENCES:
patent: 6092191 (2000-07-01), Shimbo et al.
patent: 6389532 (2002-05-01), Gupta et al.
patent: 0 689 316 (1995-12-01), None
patent: 0 898 216 (1999-02-01), None

Affiliated with

Also associated with

Rating

Secure packet processor does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Secure packet processor, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Secure packet processor will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3250066