Patent Application
20080098234
Like reference numbers and designations in the various drawings indicate like elements.
The systems, networks, devices, methods, and techniques described here can be implemented in various types of systems that implement, for example, various types of protocols (for example, a time-division multiple access (TDMA) protocol such as a time-triggered protocol such as TTP/C, SAFEbus, or FlexRay or the Institute of Electrical and Electronics Engineers (IEEE) 802.3 family of standards (also referred to as “Ethernet”) and various topologies (for example, rings, stars, chains, and/or buses topologies and topologies that make use of unidirectional and bi-directional communication links).
At least some of the data that is transmitted by and received at the node 100 is encrypted. The node 100 comprises an interface 108 for each communication link 102 to which the node 100 is communicatively coupled. In the embodiment shown in
In the particular embodiment shown in
In the embodiment shown in
Also, in such an embodiment, the node 100 expects that all data received at node 100 on link A to be encrypted with a third key 130 (also referred to here as “input key A”) and expects that all data received at node 100 on link B to be encrypted with a fourth key 132 (also referred to here as “input key B”). In this embodiment, input key A and input key B are different from one another and from output keys A and B and can be implemented in the same manner as the output keys A and B. In the embodiment shown in
In the embodiment shown in
Method 200 is performed when node 100 receives a unit of data on the incoming line 104 of interface A. When this occurs, node 100 decrypts the received unit of data using the input key (block 202). In particular, the input XOR gate A is used to XOR each bit of the received unit of data with a corresponding bit from input key A. The output of the input XOR gate A should be the plain-text version of the received unit of data (if the received unit of data was actually encrypted using input key A). The encryption-checking functionality A uses the plain-text version of the received unit of data to check if the received unit of data was actually encrypted using a key that is compatible with the input key A (block 204). A key is compatible with the input key if the input key can be used to successfully decrypt data that was encrypted using that key and the relevant encryption scheme. In this particular embodiment where symmetric encryption is used, the encryption-checking functionality A uses the plain-text version of the received unit of data to check if the received unit of data was actually encrypted using the input key A. In other embodiments, asymmetric encryption is used. For example, where public key infrastructure (PKI) encryption is used, the private key used to encrypt data is compatible with the corresponding public key that can be used to decrypt that encrypted data.
Moreover, in one implementation of such an embodiment, the plain-text version of the unit of data that is encrypted and transmitted by a non-faulty node will include a predetermined field (for example, located in a preamble, header, or Frame Check Sequence) in which a predetermine or determinable value is stored. The encryption-checking functionality A looks for the predetermined or determinable value in the predetermined field of the plain-text version of the received unit of data. If the predetermined or determinable value is there, then the encryption-checking functionality A considers the received unit of data to have been encrypted by the transmitting node using a key that is compatible with the input key A. Such unit of data is also referred to here as a “properly encrypted” unit of data. If the predetermined or determinable value is not there, then the encryption-checking functionality A does not consider the received unit of data to have been encrypted by the transmitting node using a key that is compatible with the input key A. Such data is also referred to here as an “improperly encrypted” unit of data. For example, if the transmitting node encrypted a plain-text version of the received unit of data using a key other than a key that is compatible with the input key A, then decrypting the received unit of data with input key A will not result in the proper plain-text version of the received unit of data (that is, it will not result in the plain-text version of the received unit of data that was encrypted by the transmitting node using the other key). Typically, this results in a value other than the predetermined or determinable value being stored in the predetermined field. In other implementations, the determination as to whether the received unit of data was actually encrypted using a key that is compatible with the input key A is made in other ways such as by comparing the plain-text data to similar plain-text data received via another link. Interface B processes data received on the incoming line 104 of interface B in the same way using the input XOR gate B and the input key B. In one implementation, each interface 108 includes appropriate delay elements or other functionality to keep each of the input keys 130 and 132 synchronized to the data received on the respective interface 108.
The encryption-checking functionality 118 of node 100 checks if the received unit of data was properly encrypted data (block 206). If the received unit of data was not properly encrypted, the fault-containment functionality 120 of node 100 takes a fault-containment action (block 208). In one implementation of such an embodiment, the fault-containment functionality 120 causes the node 100 to not relay the received unit of data. If the received unit of data was properly encrypted, the fault-containment functionality 120 checks if the received unit of data with transmitted and received correctly (block 210). For example, in one implementation of such an embodiment, the node 100 implements a TDMA protocol in which each node in a network is scheduled to transmit during one or more time slots of a given TDMA round. In such an implementation, when a properly-encrypted unit of data is received, the fault-containment functionality 120 checks if it is appropriate for the transmitting node to transmit during the current time slot of the current TDMA round. If not, then the received unit of data would not be considered to have been transmitted correctly because the transmitting node was not scheduled to transmit at that time.
If the received unit of data was transmitted and received correctly, the fault-containment functionality 120 considers the plain-text version of the received unit of data to be valid data and permits the plain-text version of the received unit of data to be relayed from one link 102 to the other link 102. The plain-text version of the received unit of data is relayed by encrypting (block 212) and transmitting such unit of data as described above (block 214). Also, the plain-text version of the received unit of data is also used by any higher-layer processing performed by the node 100 (for example, by application software executing on a programmable processor included in the node 100) (block 216). If the received unit of data was not transmitted and received correctly, the fault-containment functionality 120 does not consider the plain-text version of the received unit of data to be valid and takes a fault-containment action (block 218). In one implementation of such an embodiment, the fault-containment functionality 120 causes the node 100 to not relay the received unit of data from one link 102 to the other link 102. In such a case, the plain-text version of the received unit of data is not used by any higher-layer processing performed by the node 100.
In other embodiments, other fault-containment actions are taken by the fault-containment functionality 120. For example, in one such alternative embodiment, a node 100 may relay (and/or use for higher-layer processor) some or all of the improperly encrypted unit of data but flag or mark that unit of data as not be trusted (or otherwise indicate that the unit of data was improperly encrypted or not transmitted and received correctly, for example, by modifying the unit of data or adding data to the unit of data).
Other embodiments can detect shorts through or around the fault-containment functionality 120 by comparing a suitably decrypted signal from an incoming line 104 (for example, the input to the fault-containment functionality 120) with a suitably decrypted signal from the corresponding outgoing line 106 (for example, the output of the respective output XOR gate subsequently XORed a second time with the output key) and determining that a short has occurred if this comparison does not match the value expected for a correctly behaving fault-containment functionality 120. For example, some of the most common designs of fault-containment functionality 120 have at their core a simple AND gate and an Enable signal. Thus, a representative equation for the transformation of a signal from an incoming line 104 to a corresponding outgoing line 106 would be:
Output—B=((Input—A⊕Input_Key—A) AND Enable)⊕Output_Key_B
To monitor for shorts through or around the fault-containment functionality 120, one or both of the following logic equations could be used:
Check_Enable_On=(Output—B⊕Input—A)⊕(Input_Key—A⊕Output_Key—B)⊕1
Check_Enable_Off=(Output—B⊕1)⊕Output_Key_B.
followed by the use of one or both of:
Short_Detected=Check_Enable_On⊕Enable
Short_Detected=Check_Enable_Off⊕Not Enable.
Check_Enable_On should have the logic value True when Enable is on (that is, True) and there is no short through or around the fault-containment functionality 120. Check_Enable_Off should have the logic value True when Enable is off (that is, False) and there is no short through or around the fault-containment functionality 120. Note that the order of evaluation in each check equation is purposely different from the order of evaluation in the transformation equation to preclude any commonality between them. When using hardware synthesis tools to create an implementation of these equations, the resulting logic should be checked to ensure that no gates are shared between the transformation functionality and the check functionality.
It is to be understood that the embodiments shown in
Plain Text=Encrypted Input A⊕Input Key A
Encrypted Output B=Plain Text⊕Output Key B
Which is equivalent to:
Encrypted Output B=Encrypted Input A⊕Input Key A⊕Output Key B
For example, in one alternative embodiment, to reduce the delay between input and output, the plaintext version of the input unit of data is not used for relaying or for checking if the received data was encrypted using a particular key; instead, a first translation key is stored at a node that is equal to the input key A XOR'ed with output key B and a second translation key is stored at the node that is equal to the input key B XOR'ed with output key A. Then, when encrypted unit of data received on interface A (Encrypted Input A) is to be relayed on interface B, any encrypted unit of data received on interface A is XOR'ed with the first translation key. That is:
Encrypted Output B=Encrypted Input⊕First Translation Key
The various components node 100 (including without limitation the XOR gates) can be implemented in hardware, software, and combinations thereof.
In the example shown in
Where node D has a fault that causes node D to transmit a unit of data to node A at an inappropriate time (for example, where node D has a fault that causes node D to be a “babbling idiot”), interface B of node D will encrypt and transmit the unit of data on the communication link 322 using key D in the manner described above in connection with
When node B receives on its interface A the unit of data initially transmitted by node D, the received unit of data is decrypted using key AB by node B. However, the encryption-checking functionality 118 of node B will determine that the received unit of data was not encrypted using key AB (because it was encrypted at node D using key DA). As result, the received unit of data will not be considered a properly encrypted unit of data and will not be relayed to node C or used by node B for higher-layer processing performed by node B. In this way, such a short fault can be contained.
The systems, devices, methods, and techniques described here may be implemented in other ways in other embodiments. For example, other network topologies can be used, such as star topologies and braided-ring topologies.
In one implementation of such an embodiment, the bus-guardian node 402 decrypts at least a portion of the data it receives using an appropriate input key, checks if the resulting plaintext version was encrypted using the input key, and then encrypts at least a portion of the plaintext version with an appropriate output key before relaying the encrypted data. In another implementation, the bus-guardian node 402 does not decrypt the data it receives (and, therefore, does not use a plaintext version of the received data for relaying or for checking if the received data was encrypted using a particular key); instead, in such an implementation, the bus-guardian node 402 encrypts the received encrypted data using a translation key as described above before relaying the encrypted data (which was encrypted using the translation key). The fault-containment functionality included in the bus-guardian node 402, in such an implementation, determines if a particular received unit of data should be relayed by determining if some condition or policy is met that is not dependent on whether the received unit of data was properly encrypted.
An example of a braided-ring topology in which the techniques described here can be employed is described in U.S. patent application Ser. No. 10/993,936, titled “SYNCHRONOUS MODE BROTHER'S KEEPER BUS GUARDIAN FOR A TDMA BASED NETWORK,” filed on Nov. 19, 2004, which is also referred to here as the “'936 application” and which is hereby incorporated by reference in its entirety.
In general, the number of keys that is used in a given system or network is dependent on the number of communication links going into a given node, the number of links going out of a given node, the points where link-to-link shorts are physically possible, or some combination (depending on the particular topology that is employed). For example, in a network that employs a braided-ring topology of the type described in the '936 application where the nodes are distributed (i.e. nodes are far enough apart that shorts between nodes that aren't nearest neighbors on a ring is physically impossible), each node would use four (4) keys and the network total could be as little as six (6) unique keys. In a network that employs a braided-ring topology of the type described in the '936 application nodes aren't sufficiently distributed, additional keys will be needed. The minimum number of keys needed in a given system or network can be determined from the chromatic index of graph coloring theory with the vertices taken as the network's nodes plus all points where link-to-link shorts are physically possible. The number of keys used in a given system or network may exceed the minimum number derived from graph theory. Having a number of keys in excess of the minimum required may be desirable to simplify implementation or to provide other benefits; for example, maintaining DC balance on the encrypted signals.
Although the link cryptographic techniques described in connection with
In general, wherever signal lines from two different communication links are physically located near each other (where there is chance that a short between the two lines may occur), the data communicated over the two signal lines should be encrypted and decrypted using different keys. For example, it may be the case that signal lines that appear to be distantly separated in a logical diagram may actually be adjacent in a physical layout, in which case different keys should be used to encrypt and decrypt data that is communicated over those lines. To implement such a network, design rules can be defined that constrain the physical layout and/or the assignment of keys to provide the desired protection for the physical layout used. In other embodiments, failure detection using such cryptographic techniques is used for other purposes such as determining if cables have been connected to their proper termini.
The keys that are used by each node in a network can be assigned a priori. Alternatively, the nodes can engage in a key discovery process in order to determine which keys should be used. For example, in one implementation, the output key that is used by each node in a network is derived from an identifier associated with that node and an identifier associated with the interface with which that key is used. If each node in the network knows (or can learn) the identifier of each node and interface with which that node is able to communicate, that node can calculate a respective input key for communicating with each such other node. For example, where a ring topology is used in which the node identifiers are assigned sequentially and each node's interface A is coupled to another nodes interface B (where each node uses the same identifier for interface A and interface B), a given node can determine the identifier of its two neighbors by adding or subtracting one from its own node identifier (assuming each node knows the lowest and highest node identifiers in the network and account therefor) and using the appropriate interface A or interface B identifier.
In one such implementation, the bottom three bits of each node's identifier are used as the upper three bits of that node's output keys, with the fourth bit set to one bit value for that node's output key A and with the fourth bit set to the other bit value for that node's output key B. For rings of eight or less nodes, there would be no physical topology constraints. For rings of more than eight devices, there would be a physical layout constraint that no output signals from nodes with the same lower three bits in their identifier could be physically adjacent. Such a constraint typically should not be difficult to meet.
Although the embodiments shown in
Moreover, it is to be understood that techniques described here can be used in with communication devices, methods, and networks that use “store-and-forward” techniques and communication devices, methods, and networks that do not use “store-and-forward.”
Other embodiments which require DC-balanced signaling can perform the encryption described by inverting known DC-balanced sequences according to bits in the key. For example, each data bit in Manchester encoding consists of the encoded bit pair 01 or the encoded bit pair 10. If the first key bit is XORed with the first encoded bit pair, the second key bit is XORed with the second encoded bit pair, and so on until the Nth key bit is XORed with the Nth encoded bit pair, DC balance is maintained. The same idea of encoding multiple bit sequences of the data stream with a single bit of a key can be applied to codes, such as 8B/10B, that are designed to minimize DC unbalance (disparity) rather than having all DC-balanced symbols. For these codes, the number of bits in the data stream that are encrypted for each key bit may not be a fixed number and the number may have to be determined dynamically.
Although keys are typically short (on the order of a nibble), some large, highly complex topologies that cannot have signal routing suitably constrained and could require large keys. Large keys combined with multiple-bit encryption (for example, to maintain DC balance) could require a large number of data bits to be encrypted in order to fully use all of the key bits (which is needed to ensure that all possible shorting fault scenarios are covered). If the number of data bits that need to be encrypted is larger than the message size, the message could be padded out to the required length; but, a more bandwidth efficient mechanism may be to reserve a field in the message. The data values that may be used in this field can be selected from those data values with the appropriate DC balance or disparity. The encryption, then, is restricted to this field and can be seen as a simple substitution with each data value having a correspondence with only one key. For encoding systems that allow for some DC balance disparity, a homophone for each allowed level disparity can be associated with a key.
Also, although the embodiments shown in
In one such embodiment, only special test messages are encrypted in this manner (for example, to detect shorts of the type described here) and the data that is encrypted and decrypted can be data that is not otherwise used (for example, a constant value such a zero).
In another embodiment, such encryption techniques are used when a node enters a test mode. One example of such a test mode is a test mode that implements at least a portion of the functionality specified in Institute of Electrical and Electronics Engineers (IEEE) 1149 “JTAG” boundary scan standard. Conventionally, a boundary scan is used to find opens and shorts in signal wires that would prevent proper operation of a device in the node. In one embodiment, such encryption testing is used, not to find opens and shorts that would prevent proper operation, but to find shorts between redundant signals that, in absence of another fault, would not cause improper operation.
The methods and techniques described here may be implemented in digital electronic circuitry, or with a programmable processor (for example, a special-purpose processor or a general-purpose processor such as a computer) firmware, software, or in combinations of them. Apparatus embodying these techniques may include appropriate input and output devices, a programmable processor, and a storage medium tangibly embodying program instructions for execution by the programmable processor. A process embodying these techniques may be performed by a programmable processor executing a program of instructions to perform desired functions by operating on input data and generating appropriate output. The techniques may advantageously be implemented in one or more programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Generally, a processor will receive instructions and data from a read-only memory and/or a random access memory. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and DVD disks. Any of the foregoing may be supplemented by, or incorporated in, specially-designed application-specific integrated circuits (ASICs), complex programmable logic devices (CPLDs), or field programmable gate arrays (FPGAs).
A number of embodiments of the invention defined by the following claims have been described. Nevertheless, it will be understood that various modifications to the described embodiments may be made without departing from the spirit and scope of the claimed invention. Accordingly, other embodiments are within the scope of the following claims.
