DE69125756T2 - Method and device for decrypting an information package with a modifiable format - Google Patents

Description

BACKGROUND OF THE INVENTION

This invention relates generally to computer networks, and more specifically to techniques for encrypting and decrypting messages transmitted over networks. The following background material under the subheadings "Computer Network Background" and "Cryptography Background" introduces various computer network and cryptography concepts and definitions. Those familiar with computer networking and cryptography may wish to skip these two sections.

Computer Network Background:

A computer network is simply a collection of self-contained computers connected together to share hardware and software resources and to increase overall reliability. The term "local area network" (LAN) is usually applied to computer networks in which the computers are located in a single building or in adjacent buildings, such as a university campus or a single corporate office. When the computers are farther apart, the terms "wide area network" or "long haul network" are used, but the distinction is gradual and the definitions occasionally overlap.

A bridge is a device connected to at least two LANs and used to route message frames between LANs so that a source station of one LAN can send data to a destination station of another LAN independently from the destination. Bridges are useful and necessary network components, primarily because the total number of stations in a single LAN is limited. Bridges can be implemented to operate at a selected protocol layer of the network. A detailed knowledge of network architecture is not required to understand this invention, but a brief description is given below for further background.

In the development of computer networks, various approaches have been made to the choice of communication medium, network topology, message format, channel access protocols, and so on. Some of these approaches have become de facto standards. Several different models of network architecture have been proposed and widely adopted. The model most widely adopted is the International Standards Organization (ISO) Open Systems Intercommunications Reference Model (OSI). The OSI Reference Model is not itself a network architecture. Instead, it specifies a hierarchy of protocol layers and defines the function of each layer in the network. Each layer in one computer in the network carries on a conversation with the corresponding layer in another computer with which the message exchange takes place, in accordance with a protocol defining the rules of that message exchange. In reality, information is passed down from layer to layer in one computer and then through the channel medium, and up through successive layers in the other computer. However, for the design of the different layers and for understanding their functions, it is easier to compare each of the layers as its counterpart on the same level to be viewed as communicating in a "horizontal" direction.

The lowest layer defined by the OSI model is called the physical layer and is concerned with the transmission of raw data bits over the communication channel and ensuring that the data bits are received without errors. The design of the physical layer involves areas of electrical, mechanical or optical engineering, depending on the medium used for the communication channel. The layer after the physical layer is called the data link layer. The main task of the data link layer is to transform the physical layer, which interfaces directly with the channel medium, into a communication link with the next layer above, known as the network layer. This channel can lose entire packets, but it does not corrupt data in any other way. The data link layer performs functions such as structuring the data into packets or frames and adding control information to the packets or frames, such as checksums for error detection and packet count.

Although the data link layer is essentially independent of the type of physical transmission medium, certain aspects of the data link layer function are more dependent on the transmission medium. Therefore, in some network architectures, the data link layer is divided into two sublayers: a logic control sublayer (LLC layer), which performs all medium-independent functions of the data link layer, and a media access control sublayer (MAC sublayer). The MAC sublayer determines which station should be granted access to the communication channel when there are conflicting access requests. The functions of the MAC Lower layers are more likely to depend on the type of transmission medium.

Bridges can be designed to operate in the MAC sublayer. For more details, see "MAC Bridges," P802.1D/D6, September 1988 (and later versions), a pre-publication of IEEE Project 802 on standards related to local and metropolitan area networks.

The basic function of a bridge is to listen to message traffic "indiscriminately," that is, completely on all LANS to which it is connected, and to send some of the messages it hears to LANs other than the one from which it heard the message. Bridges also maintain a database of station locations derived from the content of the messages it forwards. Bridges are connected to LANS by paths known as "links." After a bridge has been in operation for some time, it can assign virtually every station a special link connecting the bridge to the LAN, and can then forward messages more efficiently, transmitting only over the appropriate link. The bridge can also recognize a message that should not be forwarded because the source and destination stations are reached over the same link. Except for its function of "learning" station locations or at least station directions, the bridge basically works as a message repeater, passing messages from one LAN to another until they reach their destinations. Other devices known as routers are also used to connect the LANs to each other.

A router, like a bridge, is a device that is connected to two or more LANs. Unlike a bridge, however, a router operates at the network layer level rather than the data link layer level. Network layer addressing makes use of a large address field (e.g., 20 bytes) for each host computer that contains a unique network identifier and a host identifier within the network. Routers use the destination network identifier in a message to determine an optimal path from the source network to the destination network. Routers can use various routing algorithms to determine the optimal paths. Typically, routers exchange information regarding the identities of the networks to which they are connected.

Document EP-A-0 289 248 discloses a programmable protocol engine to provide more effective communication between networks using different protocols. It includes a core central processor having several programmable finite state machines that operate concurrently and interact with each other. Satellite processing units, connected via interfaces to the core central processor, perform operations concerning the format of incoming and outgoing messages. Programmability is achieved by realizing the satellite units by combinations of a processing unit and a memory unit storing instructions. The sequence of instructions to be executed is adapted to tasks related to protocol implementations. Necessary instructions are loaded via ports, thereby implementing a chosen protocol.

When cryptography is used to protect data transmitted over a computer network, some Network devices such as bridges and routers require special processing. For example, an encrypted message should not generally be decrypted by a router that simply forwards the message to an adjacent LAN. As will also become clear later in this description, cryptography as applied to networks presents some problems that are not encountered in a more conventional application of cryptography in point-to-point communication. As a message moves down through the various protocol layers of the sending station, each layer adds its own header per message, which can be segmented into standard-sized data frames. The headers added at the various protocol layers contain addressing information and other information used for directing a message frame to its intended destination and for reconstructing the message at the destination. Encryption is usually applied only to the message content, not to the various message headers. Although this is not a difficult concept, in practice complexities arise because different network protocols may be used at any given protocol layer. Therefore, a hardware-implemented network cryptography system must be able to handle message frames originating from these different protocols, which necessarily have different frame formats. Furthermore, each of these frames can be segmented into smaller frames as it moves through the various inter-network links.

Cryptography background:

The main purpose of encryption is to protect the exchanged data from unauthorized interception. This is generally referred to as the "secrecy" or "confidentiality" requirement of cryptographic systems. A related requirement is the "authenticity" or "integrity" requirement, which ensures that the information exchanged is genuine, ie has not been falsified intentionally or inadvertently. For further discussion, some definitions are necessary.

"Plaintext" is used to refer to a message before encryption and after decryption by a cryptographic system. "Ciphertext" is the form that the encrypted part of the message takes during transmission over a communication channel. "Encryption" is the process of converting plaintext into ciphertext. "Decryption" is the process of converting ciphertext into plaintext. Both encryption and decryption are controlled by one or more "encryption codes". Without knowledge of the encryption code, a message cannot be encrypted, even if the encryption process is known. Likewise, without knowledge of the decryption code, the message cannot be decrypted, even if the decryption process is known.

More precisely, a cryptographic system can be imagined as having an encryption transformation Ek defined by an encryption algorithm E used in all encryption operations and a key K that distinguishes Ek from other operations using the algorithm E. The transformation Ek encrypts a plaintext message M into an encrypted message or ciphertext C. Similarly, decryption is performed by a transformation Dk defined by a Decryption algorithm D and defined by a key K.

Dorothy E. R. Denning suggests in "Cryptography and Data Security", Addison-Wesley Publishing Co. 1983, that for complete secrecy of the transmitted message, two requirements must be met. The first is that it should not be possible for anyone to systematically determine the decryption transformation Dk from the intercepted ciphertext C, even if the corresponding plaintext M is known. The second is that it should be systematically impossible to systematically determine the plaintext M from the intercepted ciphertext C. The authenticity requirement is met if no one can replace the ciphertext C with a false ciphertext C' without detection.

To expand on the background, cryptography systems can be classified as either "symmetric" or "asymmetric". In symmetric systems, the encryption and decryption keys are either the same or can be easily determined from one another. If two parties wish to communicate using a symmetric cryptography system, they must first agree on a key, then the key must be transmitted from one party to the other by some secure means. This usually requires that the keys be agreed upon in advance, the keys be changed in an agreed time table, and that they be sent by mail or some other secure method. Once the keys are known to both parties, the exchange of messages using the cryptographic system can begin.

An asymmetric cryptography system is a system in which the encryption and decryption keys differ in such a way that at least one key cannot be computationally determined from the other. Thus, one of the transformations Ek or Dk can be revealed without compromising the others.

In the mid-1970s, the concept of a "public key" cryptographic system was introduced. In a public key system, each user has a public key and a private key, and two users can communicate with each other if they only know each other's public keys. This allows a secure communication channel to be created between the two users without the two users having to exchange "secret" keys before communication can begin.

In general, asymmetric cryptographic systems require more "computational effort" for both encryption and decryption than symmetric systems. Therefore, a common development has been a hybrid system in which an asymmetric system such as a public key system is first used to create a "session key" to be used between the two parties wishing to communicate. Then, this shared session key is used in a conventional symmetric cryptographic system to transmit messages from one user to the other.

Cryptography in networks:

Although cryptographic principles may be designed simply when point-to-point communications are concerned, additional problems arise when the communication takes place over a complex computer network. A single message exchanged between one station and another may pass through many stations and through many LANs before reaching its final destination. A fundamental design question is whether the encryption should be "end-to-end" encryption, that is, with an encryption process at the source station and a decryption process at the final destination station, or "link" encryption, that is, with encryption and decryption taking place before and after the transmission "hop" over each intermediate communication link over which the message passes. Various combinations of end-to-end encryption and link encryption are possible. Standardization in the area of network cryptography is still under development. One effort aimed at standardization is the Standard for Interoperable LAN Security (SILS), an ongoing effort of an IEEE 802.10 subcommittee aimed at standardizing "data link layer" encryption for a LAN.

In general, end-to-end encryption is preferred because it provides a higher level of data security and authenticity, since messages are not decrypted until they reach their final destinations. However, any addressing information or the early parts of the frame containing the network addresses must not be encrypted in end-to-end encryption, because intermediate stations or nodes need them for message forwarding. One of the practical difficulties in using cryptography in computer networks is that a received message packet may contain both plaintext data and such as frame headers added by the various layers of the network protocol, and encrypted data, which usually makes up the bulk of the packet. A further complication is the possible presence of multiple protocols at the same level. Ideally, a network cryptography system must be able to handle these different protocols without modifying the hardware or the software that performs the encryption or decryption operations.

A related problem is that the upper layer network protocols are subject to occasional revision by manufacturers or by industry standards committees. Therefore, an ideal network cryptography system is one that is immune to changes in the upper layer protocols, specifically in the network layer or above.

Another difficulty is that network architectures without cryptography are already well established. The addition of cryptographic functions must ideally be done without affecting the continued operation of these existing architectures. In other words, cryptography should be implemented as a simple hardware solution that fits current architectures with the least possible changes.

In the past, cryptographic processing in the network environment has been performed in a manner best described as "store-process-forward." A data packet to be encrypted or decrypted is stored in a packet buffer, then read out for cryptographic processing, and finally forwarded after processing. In some designs, the packet buffer has many ports to accommodate a large amount of incoming data. can be stored while other data in the buffer is processed by encryption/decryption software in a host computer system. In other designs, two packet buffers are present, one of which is filled with incoming data while the other is emptied and processed cryptographically. These requirements for multiple buffers or increased packet buffer size necessarily impose cost and performance constraints on the host processor. Furthermore, there is a necessary delay in processing each packet at both the sending and receiving ends.

In this document, the term encryption is used to encompass cryptographic processing that provides either "confidentiality and integrity" or "integrity only" protection of the data. In the former case, the message and checksum are encrypted before network and MAC headers are appended. In the latter case, the message is in plaintext but an encrypted checksum is appended to the message. Similarly, the term decryption is used to encompass cryptographic processing that includes both the recovery of plaintext by recovering and verifying a checksum from encrypted data and the verification of the integrity of a message that is only "integrity" protected.

From the foregoing, it is clear that there is still a need to improve cryptographic processing for computer networks. Ideally, cryptographic processing should not place special demands on packet storage at a station, should not introduce significant delay or latency into the processing of each packet, and should be convenient to existing network architectures that do not include cryptographic processing. The present invention is directed to these goals.

SUMMARY OF THE INVENTION

The present invention is disclosed in claims 1 and 4. Claims 2, 3 and 5 disclose further embodiments of the invention.

The present invention is a method and apparatus for processing the decryption of information packets conforming to a format that may be modified if protocol names are modified in the future. According to the invention, an encryption processor includes programmable register means for storing key parameters of an encrypted packet format that has been subject to change.

The invention relates in a broad sense to a method and apparatus for pipeline decryption of a received information packet having a modifiable format, the apparatus being characterized by: programmable register means containing information enabling a received information packet to be identified as an information packet of a particular protocol type requiring decryption, and further information indicating the location of an encrypted data field in the packet; means for analyzing each incoming packet on the basis of the information stored in the programmable register means to identify packets of the particular protocol type requiring decryption; and means for decrypting data fields of the incoming packets identified as Packets of a particular protocol type have been identified, with decryption being started at a location specified by the information stored in the programmable register device.

As described herein, the analyzing step includes locating a cryptographic identifier field in the received packet using an identifier offset value stored in the programmable register means; comparing a value contained in the cryptographic identifier field of the packet with a cryptographic identifier value stored in the programmable register means to determine if the packet is a particular protocol type requiring decryption; and, if the comparing step results in a match, skipping a portion of the packet indicated by a second offset value stored in the programmable register means to perform decryption of a data field starting at the correct location.

In relation to the apparatus, the invention includes programmable register means comprising information enabling identification of a received information packet of a particular protocol type requiring decryption and other information indicating the location of an encrypted data field in the packet; means for analyzing each incoming packet on the basis of the information stored in the programmable register means to identify packets of the particular protocol type requiring decryption; and means for decrypting data fields of incoming packets identified as having the particular protocol type, the decryption starting at a location specified by the information stored in the programmable register device.

A programmable register means includes means for storing (i) an offset from a reference field indicating the location in the packet of an identifier field that should contain a key identifier, (ii) an identifier value that should be found in the identifier field to indicate that the packet is a special protocol packet requiring decryption, and (iii) a second offset value indicating the start of encrypted data in the packet. The programmable register means includes a first register for storing an offset indicating the location in the packet of an identifier field that should contain a key identifier; a second register for storing an identifier value that should be found in the identifier field to indicate that the packet is a special protocol packet requiring decryption; and a third register for storing a second offset value indicating the beginning of the encrypted data in the packet.

From the foregoing, it will be apparent that the present invention represents a significant advance in the field of cryptographic processing for communications networks. In particular, the invention facilitates decryption processing of information packets having a format that can be modified as protocol standards in the communications industry evolve. The use of programmable registers to store code packet format parameters and identifiers simplifies or eliminates redesign of the cryptographic processor, if a change is made in the packet format or the cryptographic identifier.

BRIEF DESCRIPTION OF THE DRAWINGS

A more detailed understanding of the invention can be obtained from the following description of a preferred embodiment, given by way of example only, and to be understood in conjunction with the accompanying drawings, in which:

Figures 1a-1c are block diagrams of various conventional implementations of cryptographic processing in a network environment;

Figure 2 is a block diagram showing how cryptographic processing is implemented in accordance with an aspect of the present invention;

Fig. 3 is a block diagram of a cryptographic processor incorporating the claimed invention;

Figures 4, 5, 6a, 6b, 7 and 8 are flow charts showing functions performed by the cryptographic processor in a parsing operation on a received information packet;

Figures 9a-9b are diagrams of two types of SNAP/SAP packet formats;

Fig. 10 is a diagram of an ISO end-to-end packet format ;

Fig. 11 is a diagram of a packet format applicable to this invention and conforming to a draft of the 802.1 SILS standard dated June 2, 1990;

Fig. 12 is a diagram showing in more detail the format of a security control field in the packet formats of Figs. 9a-9b, 10 and 11;

Fig. 13 (13a and 13b) is a flow chart showing functions performed by the cryptographic processor in a parsing operation of an outgoing or looped back information packet;

Fig. 14a-14c are diagrams of three types of outgoing or loopback packet formats; and

Fig. 15 is a flowchart showing abort processing according to an aspect of the invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

As shown in the drawings for illustrative purposes, the present invention relates to cryptographic processing in the context of interconnected computer networks, referred to in this document as local area networks or LANs. There are many applications of networks in which the confidentiality or integrity of the transmitted data is important for security. Confidentiality ensures that it is, for all practical purposes, impossible for an eavesdropping person connected to the network to convert the transmitted data from its encrypted form to its original plaintext form. The "integrity" of the data refers to its protection against unauthorized or inadvertent modification.

According to one of the protocols described in this document, encryption is performed at a sending or source node, while decryption is performed at a destination node This is known as end-to-end encryption, which is in contrast to link encryption, in which decryption and re-encryption are performed at each intermediate node between the source and destination. The manner in which encryption is performed, or the encryption algorithm, is of no particular importance to the present invention. Furthermore, it is not important whether encryption and decryption keys are exchanged in advance between the sending and receiving nodes, or whether a public key system is used to establish the keys. As mentioned later in this specification, one implementation of the invention uses an encryption algorithm known as the Data Encryption Standard (DES), defined by FIPS-46 (Federal Information Processing Standard - 46) published by the National Institute of Standards and Technology (formerly the National Bureau of Standards). However, the invention is not limited to this or to any other encryption algorithm.

Typical Token Ring networks use optical fiber, coaxial cable, or twisted pair cable as the transmission medium. Such a network using the Token Ring protocol is known as a Fiber Distributed Data Interface (FDDI). The description in this document is based on FDDI interfaces and frame formats, but it would be applicable to many different network interfaces with minor modifications.

Encryption can, at least in theory, be applied to any number of protocol layers in a network architecture. In practice, it is conveniently carried out in the data link layer. Fig. 1a is a block diagram showing a data flow in the data link layer. Data packets arriving from the physical layer (not shown) are processed by the MAC processor, designated by the reference numeral 10, and then sent to a memory controller 12 which controls operations in two packet buffers 14a, 14b.

In one prior art approach, cryptographic processing as shown at 16 is performed on data read from packet buffers 14a, 14b. For data arriving from the physical layer, data packets are stored in alternating packet buffers, read for decryption by cryptographic processor 16, and forwarded in decrypted form to the next higher protocol layer. Outgoing data frames are similarly stored in packet buffers 14a, 14b, read for encryption by cryptographic processor 16, and then forwarded by memory controller 12 to MAC processor 10.

Fig. 1b shows a similar arrangement, except that there is only one packet buffer 14, which must be large enough to provide storage space for several data packets, and where two ports may be required for simultaneous access by the cryptographic processor 16 and by the MAC processor 10. Fig. 1c shows another arrangement similar to Fig. 1sb, except that the cryptographic processor 16 is not connected in series with the data paths to higher protocol layers.

As shown in Fig. 2, the cryptographic processing takes place in a "pipeline"or"Circuiting" through a cryptographic processor 16', which in this exemplary embodiment is located between the MAC processor 10 and the memory controller 12. The cryptographic processor operates at network speeds on data flowing to or from the MAC processor 10 and does not require additional packet buffer bandwidth, packet buffers, or additional processing capabilities.

Cryptographic processor hardware

As shown in Figure 3, the cryptographic processor of the invention provides a full duplex path between the MAC sublayer via a MAC interface 20 and the RMC (Ring Memory Controller) module via an RMC interface 22. The receive data path normally leads to the MAC interface 20 via input receive data lines (labeled IRPATH). The MAC interface 20 checks the parity of the data received by the MAC processor and monitors end of data control lines to keep track of the packets currently being processed. The processing and routing of the incoming data is largely controlled by a receive control state machine 24, the functions of which will be described in more detail. Basically, the receive control state machine 24 examines incoming data packets as they arrive from the MAC interface and determines what action to take, including whether to decrypt an incoming packet.

The receive data path also includes a DES (Data Encryption Standard) function module 26 of conventional design, a multiplexer 28 at the output of the DES module 26, a receive FIFO (First-In/First-Out) memory 30 and another Multiplexer 32, the output of which is connected to the RMC interface. For decryption operations, data signals received from the MAC interface 20 are input to the DES module 26, then the decrypted signals pass through the multiplexer 32 to the RMC interface 22. The multiplexer 32 selects its input from either the DES module 26, the receive FIFO 30, or a third line 34 over which data from a transmit data path to be written can be looped back to the RMC interface 22. Parity or other check codes to be written can be added to the decrypted data output by the DES module 26. The data processed in the receive data path is finally output by the RMC interface 22 over output receive lines labeled ORPATH.

The transmit data path has a similar structure to the receive data path. Data packets for transmission are received at the RMC interface over input transmission lines labeled ITPATH, checked for parity and transmitted to a transmit FIFO memory 40 and a second DES function module 42', the outputs of these two paths being selected by another multiplexer 44' for forwarding to the MAC interface and output over output transmission lines labeled OTPATH. The inclusion of a cyclic redundant code (CRC) requires the addition of a CRC generator and check module 46', another multiplexer 48' for selecting between data from the RMC interface 22 and data returned over line 50 from the output of the DES module 42, and yet another multiplexer 54' which selects between the output from the CRC generator and the input data from the RMC interface. Controlling the data flow in the transmission data path is carried out via a loopback/transmission control state machine 60. It will be noted that the multiplexer 44 provides its output in three possible paths: to the MAC interface for transmission of an outgoing data packet, to the multiplexer 32 (via line 34) for looping a data packet back to the RMC interface, and via another line 62 to a node processor interface 64 for looping a data packet back to the node processor or host processor (not shown).

The basic function of the receive control state machine 24 is to parse or analyze each incoming data packet received by the MAC interface 20 and determine how that packet should be processed. The most important decision to be made in this context is whether to decrypt an incoming packet. Based on its analysis of the header information in an incoming data packet, the receive control state machine 24 conditions the receive data path to appropriately process the incoming packet. An important aspect of parsing the incoming data packets is that it must be performed as the packet flows in from the MAC interface 20. By the time the first byte of potentially encrypted data arrives, it should be known whether decryption is required.

A similar process occurs during the transmission of data packets received from the RMC interface 22. The loopback/transmission control state machine must decide whether encryption is required based on the header information in the transmitted packet and must then condition the transmission data path to provide the appropriate transformation and routing of the data following the header information. The transmit data path handles not only packets intended to go out through the MAC interface 20, but also packets that are looped back by the cryptographic processor for various reasons. Loopback may be used by the node processor to encrypt one or more key codes before encrypting the data, or to encrypt or decrypt data and return the transformed packet to the node processor either directly or through the RMC interface 22. An important function of loopback processing is to handle false decryptions. A false decryption occurs when an incoming packet is decrypted but should not have been decrypted. When the error is discovered, the falsely decrypted packet is looped back to the cryptographic processor so that the erroneous transformation of the data can be reversed.

The receive data path:

The process of parsing incoming data packets is shown diagrammatically in the flow charts of Figures 4-8. There are many different packet formats corresponding to different network protocols used at higher levels in the hierarchy of the network architecture. Parsing an incoming packet involves the basic steps of identifying the protocol that was used to generate the packet and extracting sufficient information from the packet headers to determine whether decryption is required and, if so, what type of decryption it is and where in the packet it should begin.

Identifying every conceivable packet format would be complex and time consuming. Moreover, the present invention is not limited to parsing logic that can identify particular packet formats. For example, several different types of formats are identified in the receive data path. These formats are shown diagrammatically in Figures 9a-9b, 10 and 11. Figures 9a-9b show two variants of the packet format, known as the SNAP/SAP format, which includes a backup encryption format defined by Digital Equipment Corporation (Figure 9a), and the DOD-IP encryption format (Figure 9b), respectively. Figure 10 shows the ISO end-to-end encryption packet format, and Figure 11 shows a third format known as SILS, which is still currently being defined in the industry.

All packet formats share a MAC header, an LLC header, and a security control field (denoted SE_CTRL). Parsing the incoming packet involves first examining the MAC header to determine if the packet is of the type to be decrypted, then examining the LLC header to identify the protocol, and finally skipping the appropriate field of the packet to extract information needed to perform the decryption process. At several points in the parsing process, the decision may be made not to decrypt the packet, in which case it is simply passed through the RMC interface 22.

The first step in parsing an incoming packet is to examine the MAC header, as shown in Fig. 4. The frame control field of the MAC header contains a packet identifying field that is of the long address type or the short address type. If Long addresses are not specified (as determined in block 40), no decryption is performed and the packet is forwarded to the RMC interface 22 (as indicated in block 42). Likewise, if the frame class identified in the frame control field is not identified as LLC (block 44), no decryption is performed. Furthermore, if either the MAC destination address multiplexing bit (block 46) or the MAC source address routing information indication bit (block 48) is set, no decryption is performed.

LLC parsing involves examining the first two bytes of the LLC header to identify the protocol and the multiple paths arising from this block, as indicated in block 54 (Fig. 5). In the case of the SNAP/SAP packet format, the first two bytes of the LLC header each have a hexadecimal value of AA, i.e. a binary value of 1010 1010. In the case of the ISO end-to-end packet format, the first two bytes of the LLC header each have a hexadecimal value of FE, i.e. a binary value of 1111 1110. In all cases, the second byte does not necessarily need to be examined, but the third byte (control field) must be 03 (hexadecimal) (unnumbered information).

If in parsing the LLC header the cryptographic processor does not detect a SNAP/SAP packet (block 56, continued in Fig. 6a) or an ISO end-to-end packet (block 58, continued in Fig. 6b) or a SILS packet (block 60, continued in Fig. 7), it is decided not to decrypt (block 42) so that the packet is sent to the RMC interface 22 without further cryptographic processing.

What is referred to as SILS packet in this description does not necessarily represent a format that IEEE 802.10 (SILS) standards committee may eventually recognize it as a standard. As will be readily apparent, the disclosed embodiment is readily adaptable to handle the eventual SILS standard. However, at the time of preparation of this document, no established standard existed and any attempt at compliance would be speculative.

In further parsing of a SNAP/SAP packet (Fig. 6a), processing continues with a check (in block 62) of the protocol identification bytes (PID bytes) to determine the SNAP/SAP packet type. The detected packet types are given in the following table:

If the packet type is recognized as a digital security type, the next field to be analyzed is the security control field, as indicated at 64. For a DOD IP packet type, the IP header length (from the next byte in the packet) is saved for future use as an offset, as indicated in block 66. Then the next five bytes are skipped, after which a flag/offset field is examined (block 68). The flag/offset field has the following format:

OOOO OOOO OOOO ORDM,

where O is an offset,

r is a reserved bit position,

D the meaning "do not fragment"

owns and

M means "more fragments".

If there are no more fragments (M = 0) and the offset is zero (O = 0) as determined in block 70, processing continues. Otherwise, decryption is not performed (block 42). If processing continues, it is next determined (in block 72) whether the protocol identification byte following the flag/offset field by one byte contains the correct protocol value. The correct protocol identification for the DOD-IP protocol is initially stored in a register (called the DOD_IP PID register) associated with the cryptographic processor. If the identification is correct, processing continues with the parsing of SE_CNTRL (64).

The ISO end-to-end parsing continues, as shown in Fig. 6b, with the confirmation of the ISO IP format, in which the PID field is checked for an expected identification value (block 76). If no confirmation is found, no decryption is performed (block 42). If an ISO end-to-end packet format is confirmed, the network header length is saved (block 78), and the flag byte is examined (block 80). The flag byte contains the following information:

SMET TTTT

where S means "segmentation is allowed"

M means "more segments follow",

e indicates an error report and TTTTT indicates the packet type.

If segmentation is not permitted (S = 0), as determined in block 82, decryption may or may not be required. Segmentation could not occur, so the transport layer Header is checked to determine if decryption is appropriate. The remaining portion of the network header is skipped, and a length identifier and a security identifier from the packet are compared to "fingerprint" values (in block 86, Fig. 8). If there is a fingerprint match (block 88, Fig. 8), cryptographic processing continues with SE_CTRL parsing. If there is no fingerprint match, which is determined in block 88, no decryption is performed (block 42).

If segmentation is permitted (S = 1), decryption may still be appropriate. If there are no more segments (M = 0) and the packet type is 1C (hexadecimal), the current packet may be the entire unfragmented packet or the last fragment (or segment) of a set of segments. The remaining portion of the network header is then skipped (block 84) and security processing is performed to perform further checks (block 88). If there are more segments (M = 1), the current packet is a fragment of a larger (possibly encrypted) packet and does not need to be decrypted.

Parsing a SILS packet (Fig. 7) is a special case because the SILS format is not yet defined. All that is known for certain is that a SILS identification code is transmitted in a specific field of the packet and that the security control field SE_CTRL begins at another designated location in the packet. Therefore, to check a SILS packet, the parsing process first jumps (block 100) by a programmed offset number of bytes to a location in the packet where a SILS identification field is known to be stored.

This field is compared to a programmed SILS fingerprint value (block 102). If there is a match (block 104), processing jumps by a programmed offset to the beginning of the SE_CTRL field (block 106). If there is no match, no decryption is performed (block 42).

Once parsing of a received packet has concluded that decryption is required, the parsing process continues with an analysis of the SE_CTRL field of the packet. As shown in Figure 8, the integrity flag is first checked (block 110) to ensure that integrity checking cryptographic processing has been selected. Otherwise, or if an unavailable encryption algorithm is selected (block 112), no decryption is performed (block 42). However, if the check in block 112 is passed, appropriate flags are set (block 114) to condition the cryptographic device for decryption, whereupon decryption is started (block 116).

The loopback/transmission data path:

As discussed earlier with reference to Figure 3, a packet received by the RMC interface 22 may be either an outgoing packet for transmission through the MAC interface with or without encryption, or a packet that is not transmitted to the MAC interface but is instead subjected to a loopback for further processing by the node processor. Although these alternatives complicate the situation to some extent, the processing in the loopback/transmit data path is facilitated by the presence of a cryptographic preamble in those packets for which cryptographic processing required. Details of the cryptographic preamble will be discussed in a later section of the description, for now it is only necessary to understand that one field of the preamble contains a processing mode field, where the modes are:

000 - outgoing transmission,

001 - Looping back the code encryption

010 - Looping back the encryption

011 - Looping back the decryption and

100 - Looping back the encryption, whereby only

ICV is returned.

Figure 13 is a flow chart showing the outbound and loopback processing, while Figures 14a-14c are the packet formats of the three possible types of packets received by the RMC interface 22. As shown in Figure 13, parsing of an outbound or loopback packet begins with two pre-checks on packet request header bytes at the beginning of the packet. If an FCS field is present in the packet (block 120) or a cryptographic preamble is not present in the packet (block 122), no further cryptographic processing takes place and the packet is forwarded directly to the MAC interface 20 as indicated in block 124. Then the mode field of the encryption preamble is examined (block 126) and one of the alternative processing paths is chosen depending on the mode value in the preamble. If the mode does not have any of the permitted values, the transmission is aborted (block 128).

If the mode value is 00, which indicates outgoing encryption, an internal flag is set (TX_ENCR) to indicate that this mode is being executed (block 130), an offset is loaded to The first step is to specify the starting point of encryption (block 132) and processing continues with the parsing of the SE_CTRL field (block 134). Processing of the SE_CTRL field is essentially the same as the processing of this field in the receive data path (as shown in Figure 8). The only differences are that if various validity checks are passed, flags and values are set for encryption rather than decryption (block 114) and that instead of decrypting the code and data in block 116, encryption of the code and data is performed. If the validity checks are not passed, instead of deciding not to encrypt, a decision is made to abort the packet transmission.

If the mode value is 01, indicating loopback of the key encryption, a flag is set to indicate this (the LPBK_KEY flag) as indicated in block 136, the offset and SE_CTRL field are loaded (block 138) and processing skips packet fields to the encryption key(s) (block 140). In this processing mode, the keys (as shown in Figure 14c) are found at an offset distance after the cryptographic preamble. They are encrypted using a previously stored master key (block 142). The cryptographic preamble is looped back with the encrypted keys. The loopback path to either the node processor interface 64 or the RMC interface 22 is determined by a mode register which is set to indicate in one of its fields which loopback path is to be used.

If the mode value is 10, indicating that loopback encryption processing is required, two flags are set to indicate this: a TX_ENCRYPT flag and an LPBK flag, as indicated in block 144. An offset value is loaded to indicate the starting point of the data to be encrypted (block 146), and processing continues with the parsing of the SE_CTRL transmission (block 134). The data in the packet is subjected to the encryption processing defined in the SE_CTRL field, with the entire packet being looped back along the designated path to the node processor.

If the mode value is 11, indicating that loopback decryption processing is required, the flags set are a TX_DECRYPT flag and the LPBK flag, as indicated in block 148. Then, processing continues in block 146, where the loopback process is similar, except that the data is subjected to decryption instead of encryption.

From Figures 14a-14c, there are three possible packet formats for the information received from the RMC interface 22. The first (Figure 14a) is that of an outgoing packet, for which no encryption services are required, as indicated in the packet request header at the beginning of the packet. The second format (Figure 14b) is that of an outgoing or loopback data packet, for which encryption services are required. The packet contains a cryptographic preamble used to simplify transmit/loopback processing, which is extracted from the packet before an outgoing transmission occurs, but left in the packet if a loopback is invoked. The third format (Figure 14c) is that used for encryption of one or more Its cryptographic preamble contains a flag/offset field and a security control field (SE_CTRL field), but no transmission code (XMT) because a master code is used to encrypt the codes that follow in the packet. Since this is a loopback operation, the preamble is again passed back along with the packet.

This concludes an overview of the operation of the cryptographic processor of the invention for processing packets received from MAC interface 20 for possible decryption and packets received from RMC interface 22 for either encryption or transmission or loopback to the node processor after encryption or decryption. More specific aspects of the preferred embodiment(s) are further discussed in the following subsections.

Stochastic decryption:

For various reasons, not all received data packets should be decrypted in the cryptographic processor 16' (Fig. 2). It is possible to determine from the packet headers added at the various protocol levels whether the data in the packet needs to be decrypted. However, careful analysis of the headers significantly increases the complexity of the parsing algorithm and may require the cryptographic processor to include a database of protocol identifiers. In addition, minor changes in the header standards would require corresponding changes in the cryptographic processing to determine whether decryption is required.

To avoid exhaustive header analysis or parsing time and to minimize the need for continuous updating of the cryptographic processor, the processor decides on a stochastic basis, after an incomplete analysis of the packet headers, whether decryption is required. Basically, checks are made for a limited number of protocol formats, with decryption initiated or bypassed as a result of these or other relatively simple checks of the header information. If the decision is made incorrectly, either the packet data is decrypted when it should not have been decrypted, or the packet data is not decrypted when it should have been. The incorrectly decrypted packet is forwarded to the next higher protocol level and may be detected as incorrectly decrypted. The packet is then "looped back" through the cryptographic processor, which undoes the decryption and re-routes the data packet through the RMC interface 22.

The loopback process is obviously inefficient in cryptographic processing, but this is not a significant disadvantage for the overall process because the probability of such loopbacks is kept at a very low level. In the particular implementation described and given common protocols, the expected probability is on the order of 1 in 224.

One difficulty with this solution, as can be seen from the specific packet formats (Fig. 9-12), is that the format of an encrypted data packet does not only begin with header information, but depending on the type of encryption requested ends with a special field called the integrity check value (ICV). This field is a specially calculated value analogous to a checksum that is calculated at the encryption end of the transmission and recalculated at the receiving end. Therefore, an encrypted packet contains the ICV field at the end of the encrypted data, but an unencrypted packet does not contain this field. In the event of erroneous decryption, the entire data packet, including the section mistakenly interpreted as the ICV field, must be recoverable.

In order to fully reverse the cryptographic processing of the packet, special handling of the ICV is required to ensure that no information is lost during a false decryption. During decryption, an exclusive OR operation is performed between the calculated ICV and the received ICV and the result is placed in the ICV field of the decrypted packet. Subsequent node processing can check whether the ICV field is zero to verify that the ICV in the encrypted packet is correct.

If the decryption is incorrect, the packet is looped back through the encryption device. The encryption algorithm is defined to include the steps of calculating the ICV value and exclusive-ORing the result with the data present in the ICV field of the plaintext packet. In an outgoing packet, this data is always zero, so the ICV in the transmitted packet is always the calculated ICV. In a packet that is looped back, this data is obtained by exclusive-ORing the original data with the calculated ICV. so that the encryption operation exactly reverses the false decryption operation.

Handling short blocks during decryption:

Cryptographic processing using the Data Encryption Standard (DES) requires that, in the preferred embodiment, data be entered into the DES processor in blocks of eight bytes each: Cipher Block Chaining (CBC). Therefore, a transmitted packet subject to encryption should contain multiples of eight bytes. At the encryption end of the transmission, it is relatively easy to meet this requirement. At the decryption end, however, it is not possible to know the length of an incoming packet at the time decryption begins. Since the main goal of this invention is to provide real-time encryption and decryption, decryption must not be delayed until a complete packet of data has been received.

There are two situations where decryption is started on a packet and the length of the decryption portion is not a multiple of eight bytes. One of these situations is the spurious decryption situation, where decryption is started based on an incorrect stochastic determination that the incoming packet is encrypted. When the end of the packet is reached, it is then found that a non-standard sized block remains for processing. The other situation is where an encrypted message has been segmented into smaller packets by an intermediate router to meet network constraints, where the encrypted portion of the resulting fragments is not a multiple of the block size. A message encrypted for confidentiality and integrity, or for integrity only, must be decrypted as a single element because the message contains at its end an integrity check value (ICV) generated from the contents of the entire message. Subsequent segmentation of the encrypted message separates the ICV field from some of the encrypted data so that the integrity check cannot be completed until the ICV field in the last segment of the message has been received. Therefore, the segmented messages should not be decrypted as separate segments, with any attempt to decrypt such a message segment being another form of false decryption.

If a non-standard block size is encountered during decryption, the non-standard block is forwarded without decryption. The node processor detects that a non-standard block has been received, either by the status of a flag specific to that purpose or by performing a length check on the received data blocks. The node processor must then perform a correction operation using the loopback feature of the cryptographic processor to transform the entire received packet back to the form in which it was received before the erroneous decryption. Then, initially, the erroneously decrypted packet is looped back to the cryptographic processor to re-encrypt the entire packet except for the last non-standard block (which was not decrypted). If this re-encrypted packet is a segment of a segmented message, the node processor must combine this re-encrypted segment with other segments arriving before or after this one and accept the entire message as a single unit for decryption. and loop back the integrity check in the cryptographic processor.

It might be thought that this relatively complex use of the loopback procedure could be avoided if segmented messages could be reliably detected on receipt in the cryptographic processor. Unfortunately, processing each message including an exhaustive segmentation check would introduce too much complexity into the design and introduce unacceptable change dependencies into the protocol standards. Instead, it relies on the use of a fast but incomplete segmentation check, keeping the probability of missing segmented messages relatively low.

Frame status coding:

In many communications protocols, a status byte is included in the tail of the packet that carries status information specific to the particular protocol. For example, the frame status in FDDI includes an error detected bit (E), an address detected bit (A), and a frame copied bit (C). Other protocols may require other protocol-specific status bits in the frame status byte. In some cases, including pipelined communications architectures, there is a need to carry additional information with the frame, and it is desirable to do this without using additional frame status bytes or otherwise reformatting the data frame. A typical frame status byte has a count field indicating the number of status bits included, and a status bit field. For example:

In this status byte, bits 5-7 contain a count of the number of protocol-specific status bits contained in bits 4, 3, 2 and 1 of the status byte. For example, as indicated in the table, a count of 1 in bits 5-7 means that there is a protocol-specific status bit PS1 at bit position 4. A count of 4 (100) in bits 5-7 indicates that bits 4-1 contain protocol-specific status bits PS1, PS2, PS3 and PS4, respectively. In this status byte format, there is room for an additional bit at bit position zero that can be used for additional status information. One aspect provides a way to store two additional pieces of status information without changing the format of the status byte and without using additional status bytes.

Two additional status bits, obtained in the manner described below, are used in the cryptographic processor to convey the following meanings to the node processor:

00: no decryption performed,

01: ISO_IP decryption performed, no errors,

10: Non-ISO IP decryption performed, no errors,

11: Decryption (end-to-end or backup) performed and errors detected.

AS0 is an additional status bit stored at bit position 0 of the status byte. AS1 is a second additional status bit stored at two bit positions of the status word depending on the value of the count field (bits 5-7). If the count is less than 4, as indicated by a zero at bit position 7, the AS1 status is stored at bit position 1 of the status byte. However, if the count is 4 or greater, as indicated by a 1 at bit position 7, bit 1 is used for the PS4 status, with the AS1 status subsequently stored at bit position 5 of the count, which is not needed when the count is 4.

This revised status byte format provides for the storage of two additional status bits in the frame status byte without the need for additional status bytes and with minimal change in the way the status byte is decoded. For protocol-specific status information, the byte is decoded largely as before, with the exception that the counts between 4 and 7 are all interpreted to indicate the presence of four protocol-specific status bits. Decoding the additional status bits is also relatively simple. Status bit AS0 is always at bit position 0, while status bit AS1 is at bit position 1 if the count is 0- 3 and is located at bit position 5 or alternatively at bit position 6 if the count is 4-7.

Abort processing in pipeline communication:

When real-time cryptographic processing is performed in series with MAC processing and packet storage processing, a pipeline of three or more processing modules or devices is present. In situations where one of the devices aborts processing, a critical question regarding the operation of the devices is whether the abort condition should be propagated to the other, adjacent processing devices in the same pipeline. A typical attempt at a solution is to propagate the abort condition to the preceding devices.

According to this aspect, the abort condition is propagated to the preceding devices if and only if a data packet related to the origin of the abort condition is still being processed by the preceding device. In other words, if the packet currently being processed by the device that initiated the abort condition has already been completely processed by the preceding device, there is no reason to propagate the abort condition in the backward direction.

For example, consider three devices, designated Device #1, Device #2, and Device #3, sequentially coupled to process incoming communication packets received by Device #1 and sent to Devices #2 and #3.

Outgoing packets are sent from device #3 to device #2 and device #1. It is assumed that during the arrival or reception operation, devices #2 and #3 are processing the same data packet. If device #3 generates an abort condition and transmits it to device #2, device #2 also aborts processing the current packet. However, if device #1 is currently processing another packet, the abort signal is not sent to device #1.

Therefore, the termination processing in a device follows these procedure steps as shown in Fig. 15:

1) Has an abort signal been received from the next device in the forward direction? If so, go to step 2).

2) Abort processing. Is the next device in the reverse direction currently processing the same packet as this device?

3) If and only if the answer in step 2) is positive, pass the abort signal to the next device in the reverse direction.

This method of handling forwarding abort conditions improves network performance because retransmission of data packets that would be unnecessarily aborted if used in another way is avoided.

Encryption mechanism using a cryptography prefix:

As mentioned previously, there are several packet formats for different protocol layers in network communications. The cryptographic processor faces a significant problem at both the sending and receiving ends of a message because of the need to locate the portion of a message packet that is to be encrypted or decrypted. One way to do this would be to provide the cryptographic processor with complete definitions of all packet formats that may be encountered. This attempted solution has two main disadvantages. First, the processing time required to analyze the packet formats at each stage of processing would be unacceptably high. Second, such a solution would require continued revision to accommodate new or revised protocol packet formats.

At the receiving or decrypting end of a transmission, this problem has been solved in part by using a stochastic procedure in which the format of an incoming data packet is analyzed quickly but to a limited extent, with decryption only being initiated if the probability is high enough to require it. False decryptions are handled by a loopback procedure in which an incorrectly decrypted packet is re-encrypted into the form in which it was received. Another feature now described addresses this problem at the transmitting end of a transmission.

The solution for outgoing message packets is to use a special cryptographic prefix that is appended to the message packet, when encryption is desired. The cryptographic preamble contains key code information and an offset (ie, a pointer) indicating the starting point in the packet at which encryption should begin. This allows the cryptographic processor to skip intermediate header information, regardless of its format and protocol, and begin encryption at the point indicated by the encryption header. The header does not affect the packet formats transmitted on a network because it is removed from the packet before transmission.

Basically, this feature prevents the transmission of incorrectly encrypted packets over the network. In addition, it greatly simplifies the implementation of the cryptographic processor, since no packet has to be subjected to a complete parsing operation or analysis to find the location of the data to be encrypted.

The cryptographic prefix has the following format:

The flag/offset field consists of four bits of flag information and a 12-bit offset that indicates the number of bytes to skip before beginning the cryptographic operation. The flag bits contain a device-specific bit, which is zero in most cases, and a three-bit mode field that indicates the type of cryptographic operation to be performed. The mode can be:

0: outgoing encryption (no loopback);

1: Looping back a CODE encryption;

2: Looping back an encryption;

3: Looping back a decryption;

4: Looping back of the ICV only.

The SE_CTRL field defines the type of cryptography process and has fields that specify a confidentiality cipher, an integrity cipher, the type of cryptographic algorithm (DES or other), the specific cryptographic algorithm mode used (such as ECB, CFB or CBC) and the size of the cyclic redundant code (CRC) to be used. The transmitted code is an 8-byte field that defines the key used for encryption.

The cryptographic prefix contains all the information needed to locate the data to be encrypted and to determine the type of encryption required, regardless of the packet format used by the various protocols. The use of the cryptographic prefix prevents the transmission of incorrectly encrypted packets on the network. Furthermore, the presence of the prefix simplifies the hardware required for encryption, since the entire packet does not have to be subjected to a parsing operation.

Use of programmable registers to facilitate decryption:

In the cryptographic processing of the received packets, the required basic information includes the location of the decrypted data in the packet and the control for the decryption to be performed, such as the Decryption key and encryption mode. The encryption preamble discussed above is not available at the receiving end of the transmission because it was removed in the network before transmission.

This situation is complicated by the fact that the standards regarding encryption in networks are still under development. There is still an immediate need for encryption hardware. A packet encrypted at the data link layer necessarily contains a field of information identifying the packets as those requiring cryptographic processing. For at least one of the protocols under development (SILS), the location of this identifying field in the packet is not yet determined with certainty. Another uncertainty is the location of the start of the encrypted data in the packet.

To overcome these problems, a feature of the present invention provides that the cryptographic processor includes three programmable registers comprising: (a) an offset from the beginning of the security header (or from the beginning of the MAC header) to a field containing the cryptographic identifier, (b) the value of the identifier that should be present to identify the packet requiring cryptographic processing for a particular protocol, and (c) an offset value indicating the beginning of the encrypted data (the offset with respect to the identifier field to another reference point in the packet).

The three hardware registers are initialized with offset and identifier values required to meet an anticipated encryption standard, however, they can be easily changed if necessary if the standard is revised. This allows the cryptographic hardware to be easily adapted to many different encryption standards.

Cryptographic processing in integrity-only mode:

In integrity-only encryption, a data packet is transmitted in plaintext, i.e. without encryption, but an integrity check value (ICV) is included in the transmitted packet to ensure the integrity or authenticity of the data. When such a packet is subjected to a loopback procedure, the plaintext data is looped back unnecessarily. According to this feature, in integrity-only loopback procedures, only the ICV field and the headers preceding the data are looped back. This reduces the amount of data that is looped back and also improves system performance.

The mechanism used to implement this feature is the cryptographic preamble which is generated for each outgoing packet of loopback packets. The cryptographic preamble contains a status field, one possible value of which indicates that the packet is intended for integrity-only encryption and for loopback. This represents a slight modification of the outgoing and loopback processing flow chart shown in Figure 13. In addition to the four operational steps described in connection with this figure, a fifth mode value (0100) is also valid, which means that integrity-only loopback encryption has been invoked. When this mode value is present in the preamble, the cryptographic processor is conditioned to only process the headers and loops back the ICV value. The data field is only calculated for the purpose of calculating the ICV value to be looped back, but it is not itself looped back to the node processor.

Encryption with selective disclosure of the protocol identifiers:

At the data link layer, a header is added to each message packet, containing fields usually called DSAP (destination service access point) addresses and SSAP (source service access point) addresses. These ordered pairs at the beginning of the logic layer (logic link player) PDU (protocol data unit) identify a network LLC (Logical Link Control Client) "client". The DSAP/SSAP pair is immediately followed by a control field, the contents of which are interpreted by the LLC sublayer. If the frame is an unnumbered information frame, it contains user data that is sent to the LLC client. Otherwise, it is a control frame that is processed in the LLC sublayer. The control field value is 03 (hexadecimal) for unnumbered information.

If the DSAP and SSAP fields contain a special value AA (hexadecimal), this identifies a sub-switching protocol commonly known as SNAP/SAP protocol. In this case, the five bytes following the control field are redefined as the protocol identifier (PID) field as shown below:

The PID contains three bytes of a single organizational identifier (OUI) that is unique to a specific company or other organization, followed by two bytes of protocol information associated with that organization. Since these headers are in the plaintext portion of each packet of information, they can be accessed by network monitors to monitor all network activity. There are three interesting cases where problems arise in data link layer encryption. In one case, a network user may not want to reveal the encryption protocol used in encrypting a packet. The other two cases involve an opposite problem, where the user wants to reveal the encryption protocol but is unable to do so. This situation can arise when using the backup encryption standard as defined by the Standard for Interoperable LAN Security (SILS), an ongoing effort of the IEEE 802.10 subcommittee aimed at standardizing data link layer encryption for networks.

Some network users, not wanting to make this protocol information available to others, might intentionally falsify the DSAP/SSAP and PID fields in their encrypted messages. If this happens, the statistical information collected by the network monitors will be corrupted to some significant extent and unreliable, at least as far as the use of the communication protocols is concerned.

This problem is avoided by assigning a special SNAP/SAP protocol identifier that indicates that the real protocol should remain hidden or anonymous. More precisely, a special value of one of the PID bytes is used to indicate the anonymity of the PID. Although network monitors cannot yet determine the true protocols used in those packets carrying the special SNAP/SAP PID value, the packets can at least be categorized as using an anonymous or unknown communication protocol rather than being falsely identified as using a real protocol.

This opposite situation arises when a network user would prefer to reveal the encryption protocol being used, but is prevented from doing so because the message must be encapsulated to indicate the encryption. In the case of SILS, which is not yet fully defined, there is a reserved DSAP or SSAP value for identifying a packet encrypted at the data link layer.

There are two categories of information packets for which the user wants to reveal the encryption protocol. One is that of an original frame targeted to SNAP/SAP, the other is that of an original frame targeted to a SAP other than SNAP/SAP.

In the case of the SNAP/SAP frame in which the protocol is to be revealed, the original protocol is stored in the last two bytes of the PID field. (Recall that the first three bytes of the PID field are the OUI which uniquely identifies the sub-switching organization.) For an encrypted frame, a selected bit in the last two bytes of the PID field is set to "1", alternatively a selected combination of bits in the same two bytes is set to a pre-selected value. The selected bit or combination of bits need not already be used in the definition of the protocol. For example, the least significant bit of the second to last byte of the PID field could be used to indicate encryption. Whenever the last two bytes of the PID field have the value xxxx xxx1 xxxx xxxx, this would indicate that the frame was encrypted. If the value is xxxx xxx0 xxxx xxxx, this indicates that there was no encryption. The bit used for this would have to be a bit that was not used to define a protocol. In this example, therefore, protocol identifiers with an odd number in the second hexadecimal position of the two-byte field could not be used. Since the PID field is entirely controlled by the subnetwork organization, it is not difficult to define a bit or combination of bits that does not conflict with the possible values of protocol identifiers.

The third interesting case also arises when a network user wants to reveal the protocol and is prevented from doing so by the SILS security encryption standard, but the original frame is destined for a non-SNAP/SAP destination. This case is handled by first framing the non-SNAP/SAP frame with an additional plaintext header of the SNAP/SAP type. As discussed above, this header has a PID field, the first three bytes of which form a unique organization identifier and the last two bytes can be used for protocol identification. This case requires the use of another special code for one of the last two bytes in the PID field. For example, the last two bytes can be 1000_0011 orig_sap. The byte containing 1000_0011 is a special code (83) indicating that the next byte "Orig_sap" contains the original SAP for the framed frame. In general, a predefined subfield could contain the special code and any other predefined subfield could contain the original SAP.

From the foregoing, it is clear that a flexibility is created whereby the underlying protocol can be exposed if desired or kept hidden without destroying the network statistics. Such flexibility can be of great importance for optional protocol exposure in security and network management.

Of course, the foregoing description contains, for the sake of illustration, implementation details specific to a particular network architecture, i.e., FDDI. It will also be apparent to those skilled in the art of network communications that the principles described can be readily adapted for use in other network architectures, possibly with different interfaces and frame formats. For example, the invention can be readily adapted for use in an Ethernet network architecture. Furthermore, although the cryptographic processing described above is best implemented in an "on-board" processor physically integrated with other conventional network processing components, the principles of the invention can still be applied when the cryptographic processing is performed by an "off-board" processor or device added to a conventional network processor or node that did not originally have cryptographic capability.

From the foregoing it is clear that the creation of a special, anonymous protocol identification code in the header of an encrypted information packet satisfies two competing needs: the need for complete anonymity and the need to obtain accurate information by monitoring network traffic. Furthermore, this invention provides the network user with the ability to selectively reveal the underlying network protocol in both SNAP/SAP frames and non-SNAP/SAP frames. It will be understood that although an embodiment of the invention has been described in detail for purposes of illustration, various modifications may be made without departing from the scope of the invention. Therefore, the invention is limited only by the appended claims.

Claims (5)

1. Apparatus for pipeline decryption of a received information packet having a modifiable format, the apparatus being characterized by: a programmable register device containing information enabling a received information packet to be identified as an information packet of a particular protocol type requiring decryption, and further information specifying the location of an encrypted data field in the packet; means for analyzing each incoming packet based on the information stored in the programmable register means to identify packets of the particular protocol type requiring decryption; and means for decrypting data fields of the incoming packets identified as packets of a particular protocol type, wherein decryption is initiated at a location specified by the information stored in the programmable register means. 2. Device according to claim 1, in which: the programmable register means comprises means for storing (i) an offset from a reference field indicating the location in the packet of an identifier field which should contain a key identifier, (ii) an identifier value which should be found in the identifier field to indicate that the packet is a special protocol packet containing a decryption, and (iii) a second offset value indicating the beginning of the encrypted data in the packet. 3. Apparatus according to claim 1, in which the programmable register device contains: a first register for storing an offset indicating the location in the packet of an identifier field that should contain a key identifier; a second register for storing an identifier value that should be found in the identifier field to indicate that the packet is a packet with a particular protocol that requires decryption; and a third register for storing a second offset value indicating the beginning of the encrypted data in the packet. 4. A method for executing a pipeline decryption of a received information packet having a modifiable format, the method comprising the following steps: Storing information enabling a received information packet to be identified as an information packet of a particular protocol type requiring decryption, as well as further information indicating the location of an encrypted data field in the packet, in a programmable register device; analyzing each incoming packet based on the information stored in the programmable register device to identify packets of the particular protocol type requiring decryption; and Decrypting data fields of incoming packets identified as packets of the particular protocol type have been decrypted, with decryption being started at a location specified by the information stored in the programmable register device. 5. The method of claim 4, wherein the analyzing step includes: placing a key identifier field in the received packet using an identifier offset value stored in the programmable register device; comparing a value contained in the key identifier field of the packet with a key identifier value stored in the programmable register device to determine whether the packet is a packet of a particular protocol type that requires decryption; and if the comparison step results in a match, skipping a portion of the packet indicated by a second offset value stored in the programmable register means, to begin decryption of a data field at the correct starting location.