Device, method, and computer program product for secure data communication

Abstract

The invention relates to devices, methods, and computer program products for secure data communication according to a network protocol having a plurality of communication layers layered into a protocol stack. Said device comprises a processor system, in which a processor, controlled by a task scheduler, executes a plurality of autonomous software modules, which each run a communication layer of the protocol stack. The software modules are linked via communication channels to the protocol stack and the protocol stack is connected to an interface framework for data communication with an external network. At least one software module uses an assigned cryptographic key for secure data communication in its communication layer. The task scheduler is configured to obtain said key from the external network via the interface framework and to distribute said key to the assigned software module.

Claims

1. A device for secure data communication according to a network protocol that has a plurality of communication layers layered into a protocol stack, said device comprising a memory and a processor system, in which a processor, controlled by a task scheduler, executes a plurality of autonomous software modules, which each run a different one of the communication layers of the protocol stack, wherein the software modules are linked via communication channels to the protocol stack and the protocol stack is connected to an interface framework for data communication with an external network, wherein to at least one software module a cryptographic key is assigned for secure data communication in the communication layer that is run by said at least one software module, and wherein the task scheduler is configured to obtain said cryptographic key from the external network via the interface framework and to distribute said cryptographic key to said at least one software module.

2. The device according to claim 1, wherein the network protocol is constructed according to an Open Systems Interconnection (OSI) reference model and each software module runs a layer of the OSI reference model.

3. The device according to claim 1, wherein each software module has an input for at least one message channel, which is connected to the task scheduler, so as to thus obtain the key.

4. The device according to claim 3, wherein the software modules can be debugged or can be switched on and off via the at least one message channel.

5. The device according to claim 3, wherein the software modules are configured to use a further key obtained from the task scheduler for secure message traffic on the message channel.

6. The device according to claim 1, wherein the task scheduler is part of an abstraction module for the software modules which is run by the processor.

7. The device according to claim 1 wherein the device is a modem or an electronic control unit (ECU) and the processor system is a single-processor system.

8. A method for secure data communication according to a network protocol having a plurality of communication layers layered into a protocol stack, wherein, in a processor system, a processor, controlled by a task scheduler, executes a number of autonomous software modules, which each run a different one of the communication layers of the protocol stack, wherein the autonomous software modules are linked via communication channels to the protocol stack and the protocol stack is connected to an interface framework for data communication with an external network, wherein to at least one of the autonomous software modules, a cryptographic key is assigned for secure data communication in the communication layer run by said at least one of the autonomous software modules, and wherein said cryptographic key is obtained from the external network via the interface framework and is distributed by the task scheduler to said at least one of the autonomous software module.

9. The method according to claim 8, wherein the network protocol is constructed according to an Open Systems Interconnection (OSI) reference module and each software module runs a layer of the OSI reference module.

10. The method according to claim 8, wherein the aforementioned at least one of the autonomous software modules obtains the cryptographic key from the task scheduler via a separate message channel.

11. The method according to claim 10, wherein the at least one of the autonomous software modules can be debugged or switched on and off via the message channel.

12. The method according to claim 10, wherein the at least one of the autonomous software modules obtains a further key from the task scheduler and uses it for secure message traffic on the message channel.

13. The method according to claim 8, wherein the task scheduler is part of an abstraction module for the autonomous software modules which is run by the processor.

14. A computer program product, embodied on a non-transitory machine-readable data carrier, implementing a method according to claim 8.

15. A computer program product, embodied on a non-transitory machine-readable data carrier, implementing a method according to claim 9.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) The invention will be explained in greater detail hereinafter on the basis of an exemplary embodiment illustrated in the accompanying drawings. In the drawings:

(2) FIG. 1 shows the system architecture of the device of the invention in a block diagram;

(3) FIG. 2 shows one of the software modules of the device from FIG. 1 in detail; and

(4) FIG. 3 shows a data flow diagram of the method of the invention at the time of the data communication of two devices according to FIG. 1 via a network.

DETAILED DESCRIPTION

(5) FIG. 1 shows a device 1 for data communication according to a layered network protocol, for example the OSI or TCP/IP reference model. FIG. 3 shows two devices 1 of this type, which communicate with one another via a network 2 and (optionally) with a central key generation entity 3, as will be explained later in greater detail. The network 2 can be, for example, the Internet, a WAN (Wide Area Network), LAN (Local Area Network), a mobile radio network and/or a wired telephone network, and the device 1 can form therein a network switch or router, a modem, a gateway or a terminal device. In the case of a telephone network, the network protocol is generally constructed in accordance with the OSI reference model, and the device 1 is for example an ISDN or ALL-IP terminal device; in the case of the Internet, a WAN or LAN, the network protocol is generally constructed in accordance with the TCP/IP reference model, and the device 1 is, for example, an ADSL or Powerline modem. The network 2, however, can also be a device-internal bus system, via which electronic components communicate with one another securely via a layered network protocol (bus protocol), for example electronic vehicle components on an on-board vehicle bus system. The device 1 can in this case be, for example, an electronic control unit (ECU), which communicates with other electronic components via the on-board bus system of the vehicle.

(6) The device 1 shown in FIG. 1 is generally implemented in software technology on a hardware processor system, which for this purposeas is known in the artcomprises power supplies PWR, memories MEM, interfaces I/F and at least one processor MP, which executes corresponding software components. The components of the device 1 illustrated in FIG. 1 are therefore software components which are present at runtime of the software in the memory MEM of the device 1 and are executed accordingly by the processor MP, as is known in the art.

(7) The processor system on which the device 1 is implemented is generally an inexpensive single-chip processor system having just one main processor MP, which executes the (software) components of the device 1 shown in FIG. 1 sequentially in the form of tasks. A task scheduler 4 is provided for this purpose, which gives the program control of the processor MP periodically and sequentially to individual software modules L.sub.1, L.sub.2, . . . , generally L.sub.i, and an interface framework module 5, see the program sequence control loop 6. The task scheduler 4 is for its part a software component and can be part of a hardware abstraction module and/or operating system or software abstraction module (Operating System Abstraction Module, OSAM) 7 which is run by the processor MP and which is also regularly operated or executed by the processor MP in the course of the loop 6.

(8) The abstraction module 7 provides an operating system environment so to speak for the software modules L.sub.i, for example for providing timers, for the management of dynamic memory requests, etc. and also for establishing communication channels 8, 9, via which the software modules are connected to one another or to the interface framework module 5, and for message channels 10, via which the software modules can receive control messages from the abstraction module 7 or task scheduler 4 thereof.

(9) The processor MP of the device 1 can also be part of a multi-processor system, which forms a grouping of individual devices 1. Here, a plurality of devices 1 can share a processor MP, or one device 1 can have a number of processors MP. In a multi-processor system of this type, the data exchange between the devices 1 can be realised in particular also via the communication channels 8, 9 of one or more of the software modules L.sub.i.

(10) Each software module L.sub.i can have an input for more than one message channel 10. The message channel(s) 10 of a software module L.sub.i can additionally also be used to debug the corresponding software module L.sub.i or to switch it on and off for this purposelocally or by another, connected network.

(11) FIG. 2 shows the internal structure of one of the software modules L.sub.i in detail. Each software module L.sub.i is responsible for one of the communication layers of the layered network protocol which the device 1 or the method performed thereby processes. In the case of the OSI reference model, seven software modules L.sub.i (i=1 . . . 7) are provided, which each run one of the seven OSI layers. The software modules L.sub.i are for this purpose encapsulated or autonomous with respect to one another by being linked merely via the message channels 8, 9 to form a stack; the totality of software modules L.sub.i stacked one above the other is referred to as a protocol stack 11.

(12) It goes without saying that in the case of other network protocols, for example the four-layered TCP/IP reference model, only four software modules L.sub.1 (i=1 . . . 4) are necessary, each of which is responsible for the functionality of a communication layer.

(13) In accordance with FIG. 2, each software module L.sub.i for this purpose has a corresponding control program 12 and resources (provided by the abstraction module 7) for the running thereof, in particular an internal message queue 13, which records communication messages arriving via the communication channels 8, 9 and also control messages arriving via the message channel 10 for execution by the control program 12.

(14) The software module L.sub.i of the protocol stack 11 that is lowest in the layer hierarchy, here the software module L.sub.1 for the bit transfer layer of the OSI reference model or the network access layer of the TCP/IP reference model, is connected via its communication channels 8, 9 to the interface framework module 5, via which the physical data traffic is handled by the network 2. The physical interfaces I/F necessary for this purpose are presented from the interface framework module 5 to the protocol stack 11 or software modules L.sub.i thereof, abstracted from the hardware or software operating environment.

(15) The source code of a software module L.sub.i can thus be used in an embedded target environment or as a kernel mode driver of a PC operating system without having to port the source code of the software module L.sub.i. This has the further advantage that a source code for embedded systems can first be developed and tested under PC operating systems and only then can be compiled for an arbitrary embedded target system, without the source code having to be ported for the software modules L.sub.i (Portability without Porting). Due to the high degree of re-use of codes of the software modules L.sub.i, a continuous improvement of the quality of the code is also attained by Design Re-Use optimisation. There is additionally also the further advantage that performance requirements on an embedded target system, such as processor powers and requirements on the memories, can already be estimated prior to the development of the embedded target system or the ECU. Since the interfaces and communication channels of the software modules L.sub.i are specified, these can also be re-used in distributed teams of large development organisations in a simple manner.

(16) For the implementation of cryptographic security mechanisms in the network protocol processed by the device 1, one or more cryptographic keys 14 are used in one or more communication layers, i.e. in one or more of the software modules L.sub.i, for example public or private keys of public/private key encryption methods which are exchanged by two communication partners via the network 2, or common keys of shared key encryption methods, which for example are generated by the key generation central entity 3 and are distributed via the network 2, or the like.

(17) The software module L.sub.i responsible for the respective communication layer therefore requires the knowledge of the respective key(s) 14 which is/are necessary in the communication layer of said software module for the respective encryption or decryption.

(18) For this purpose, the task scheduler 4 is designed to distribute such keys 14 obtained via the network 2 and the interface framework module 5 from the external network 2 to the respective software module L.sub.i, more specifically via the message channel 10 thereof. These keys 14 can also be merely constituents of a larger, assembled or complete key, which is necessary for the encryption or decryption in the protocol layer of the software module L.sub.i. In this case a plurality of keys 14 obtained in this way from the task scheduler 4 are combined to form the necessary complete key.

(19) The keys 14 can be requested (pull) or obtained (push) for example from the abstraction module 7 via the interface framework module 5 by the communication partner in the network 2, for example another device 1 or the key generation central entity 3, and the task scheduler 4 is used merely for the corresponding distribution or delivery of the key(s) 14 thus obtained to the respective correct software module L.sub.i in the course of the program run 6. Alternatively, the task scheduler 4 itself requests or itself receives the key(s) 14 from the network 2 and sends this/these to the respective software module L.sub.i. A further possibility is that one of the higher-ranking software modules L.sub.i, in particular a software module L.sub.i of a higher application-oriented layer in the course of an application, receives one or more keys for a lower-ranking software module L.sub.i and passes this/these on to the corresponding lower-ranking software module L.sub.i via the task scheduler 4 or the abstraction module 7. Here, as well, the task scheduler 4 functions againin the course of the execution of the control loop 6as a deliverer of the respective key 14 to the corresponding software module L.sub.i via the message channel 10 thereof. A key 14 obtained from the task scheduler 4 can also be used in a software module L.sub.i to encrypt and decrypt the communication on the (at least one) message channel 10 thereof, for example for secure transfer of a following key 14.

(20) The invention is not limited to the presented embodiments, but comprises all variants, combinations and modifications thereof which fall within the scope of the accompanying claims. By way of example, the message channel 10 of the above-described device can also be used to debug a software module L.sub.i or to switch this on and offlocally or via another networkwherein the information exchange via this channel 10 can also be encrypted in accordance with the above-described methods.