Security module and secure communication method

Abstract

A computer-implemented method executed within a user control device (102) for generating and transmitting a command data packet including command data configured to operate a control unit (102), the command data having a plurality of attributes associated therewith, the method including, under control of a processor of the user control device (102), requesting a timed encryption key from a remote key issuing platform (106) and receiving the timed encryption key from the key issuing platform (106), the timed encryption key being generated by the key issuing platform using a base key selected according to a particular one or more of the attributes associated with the command data; and receiving from the key issuing platform (106) a timed encryption key together with a base key selected according to a particular one or more of the attributes associated with the command data. receiving a checksum value representing at least a subset of the attributes of the command data, including the specific attribute or attributes used by a key issuing platform (106) to select a base key; encrypting at least the command data using the timed encryption key; constructing a command data packet comprising a plain value header and an encrypted command payload, wherein the plain value header includes data representing the subset of the attributes of the command data, excluding the specific attribute or attributes used by a key issuing platform to select a base key, and the checksum value, and the command payload comprises at least the encrypted command data; and transmitting the command data packet to the control unit (102).

Description

[Technical field]

[0001] The present invention generally relates to a method of secure communication between a client device and a server, and a communications security module configured to perform such a method. [Background technology]

[0002] Cybersecurity, and specifically the security of network devices configured to receive and implement command messages from several different client devices, is an ever-evolving field of technology. At the same time that cyberattacks become more sophisticated, cybersecurity software and hardware are evolving to meet the basic need of allowing command messages from some client devices to reach the MCU and blocking command messages from other client devices, whether they represent a malicious attack or simply originate from an unauthorized user.

[0003] The most common form of security utilized in network devices is known as a firewall. A firewall is a computer network security system (or module) that restricts data packets entering, leaving, or within a private network. A firewall comprises software or dedicated hardware and software units that block or allow data packets based on a predefined set of security rules, typically intended to prevent anyone, inside or outside the private network, from participating in unauthorized communications and to help prevent malicious activity. Thus, a firewall can be considered a "gateway" that manages the movement of allowed and forbidden data packets (usually web activity) within the private network.

[0004] In recent years, it has become common for applications to use forms of encryption as an additional layer of protection for data transmitted between devices over public and private communication networks. For example, in recent years, email applications have been especially likely to use Transport Layer Security (TLS), an encryption policy derived from an earlier version known as Secure Sockets Layer (or SSL). To participate in data communications using TLS, the sending and receiving devices must have a security certificate (issued by a trusted authority). For example, when sending an email, the intended recipient sends its security certificate and a public encryption key to the sender. The sender encrypts the message using the public encryption key and sends the encrypted message to the recipient device. The recipient device can then decrypt the message using its private key. This is commonly known as Public Key Cryptography (PKC) and is well known to those skilled in the art of cybersecurity. However, this type of security is not suitable for use with MCUs (or MPUs), which are typically dedicated to a single function and are most often embedded in other devices (e.g., consumer electronic devices), because the processing and storage overhead required to support the PKC protocol, as well as the additional power consumption, are prohibitive. Also, if the recipient server does not have access to the key issuing platform, new client devices cannot communicate with that platform. Thus, for example, an IoT device with limited processing and communication capabilities could (in theory) be pre-configured to receive PKC encrypted data packets from a small number of designated client devices, but would not be able to receive such data packets from other unknown client devices. This limits the usefulness of PKC as a form of security for some applications.

[0005] Another known type of security protocol is known as HTTPS, where the client and server establish a TCP connection, followed by an SSL / TLS handshake process, and finally allowing encrypted application data to be passed between the client and server. Again, the server is client-aware and must store valid user credentials to distinguish. Validation of these initial certificates must be performed against a certificate authority, and there must also be a method of authentication and authorization for the application itself. Furthermore, certificates are only valid for a certain period of time, so the server must periodically renew them. Thus, the server must have Internet access and the appropriate software (and processing capabilities) to utilize HTTPS.

[0006] Yet another known security protocol is SSH, in which a server generates a public and private key pair for a user, the user is given the private key, and the server stores the public key for the user. When a connection is initiated between a client and a server, the server sends a random message (to the client). The client encrypts this message using the user's private key for the server, and the encrypted message is sent to the server. The server decrypts the encrypted message using the user's public key, and if the decrypted message matches the original message, authentication passes, and the client and server agree on a session key that will be used to encrypt all subsequent messages during the session. Thus, before any authentication or communication can take place, a process is required to generate user key pairs and share them with the client. The server needs to store the user key pairs, and a new key is required for each new session. Thus, not only does the server need network connectivity to support communication from new clients, but there is also a huge storage overhead if a large number of clients need to be supported, along with their respective key pairs.

[0007] There are other known security protocols, such as those involving authentication by an External Identity Provider (EIP), but these types of protocols, like those described above, require an Internet connection that allows access to an authentication server to verify that the token sent by the user is valid. For example, 4G and 5G communication networks utilize a dedicated Security Anchor Function (SEAF) that can issue a shared or "public" key used by base stations and user equipment in the communication system. For example, EP 3576446 describes a security implementation method in which a handover command is sent to a UE, thereby realizing an inter-AMF handover between two different communication systems in a communication network. The handover command message is accompanied by security context data related to the target communication system, which may be any one or more of several characteristics, including a security key lifetime, a key index, or a counter related to the key calculation. The handover command message may also include a specific key. The UE generates a security key using the intermediate key and the security context of the target communication system. The end goal is for the UE to generate a security key using the SEAF key and security context data, which is essentially the "secret" key for the UE to communicate with after the handover occurs, so the handover command is not encrypted and does not need to be encrypted. In fact, this method is similar to the SSH method described above and does not solve the technical challenges described above. The overhead required to support a dedicated SEAF is prohibitive for many (if not most) applications, making it highly unsuitable for small communication networks.The number of communications required prior to the handover command message, the processing and storage overhead required to implement the method on a large scale (as intended), and the need for a network connection to process the handover command message are all technical drawbacks that prevent this security method from being applied for use outside of large communications networks. Furthermore, the handover command needs to be generated in a specified format and according to a specified protocol. The described method is not suitable for enabling a UE to receive a command message encrypted in any format and using any protocol. It is specifically designed to enable handover of a UE from a 4G eNB to a 5G gNB.

[0008] It will be apparent to one skilled in the art that MCUs for industrial and IoT applications are necessarily power and feature limited and are not easily adapted to utilize any of the security protocols discussed above.

[0009] At the current state of the art, only traditional firewalls attempt to control data communication to and from a server in this way. In a traditional firewall arrangement, a client constructs a packet of data that includes a destination address, protocol, and destination port. The firewall is configured with allowed rules that determine which client addresses, ports, and protocols can send messages to which addresses, ports, and protocols. If the packet matches an allowed rule, the packet is sent. In many cases, the data is not encrypted at all, and even if it is encrypted, it is the responsibility of the client and server, and is achieved by pre-agreeing or negotiating keys using one of the methods described above (i.e., SSL / TLS or PKC), requiring that the receiving device has access to the Internet, as well as sufficient storage and processing overhead to manage all the user keys that need to be generated and stored.

[0010] However, in light of the increasingly widespread implementation of IoT devices, which are typically offline (to conserve power) and tend to have minimal storage and processing capabilities (to minimize costs and to some extent size), the inventors have recognized the need for a new method of authenticating data packets received by a server, which does not require the server to be connected to the Internet, does not require any external intervention to authenticate a new client when receiving a data packet (command message) from a client device (by any means including Bluetooth, SERIAL, HTTP, UART, etc.), and can process command messages from an unlimited number of different clients without the server needing to be connected to the Internet, ... Summary of the Invention

[0011] According to a first aspect of the present invention there is provided a computer implemented method executed within a user controlled device for generating and transmitting a command data packet including command data configured to operate a control unit, the command data having a plurality of attributes associated therewith, the method comprising, under control of a processor of the user controlled device:

[0012] - requesting a timed encryption key from a remote key issuing platform and receiving the timed encryption key from the key issuing platform, the timed encryption key being generated by the key issuing platform using a base key selected according to a particular one or more of the attributes associated with the command data;

[0013] receiving from the key issuing platform, together with the timed encryption key, a checksum value representing at least a subset of the attributes of the command data, including the particular attribute or attributes used by the key issuing platform to select a base key;

[0014] - encrypting at least said command data using said timed encryption key;

[0015] constructing a command data packet comprising a plain value header and an encrypted command payload, the plain value header comprising:

[0016] data representing the subset of the attributes of the command data, excluding a particular attribute or attributes used by the key issuing platform to select a base key;

[0017] the checksum value;

[0018] the command payload comprises at least encrypted command data;

[0019] To build and

[0020] - transmitting said command data packet to said control unit.

[0021] In one embodiment, the method may further comprise receiving a key expiration date together with the timed encryption key from the key issuing platform, and including data representative thereof in the plain value header of the command data packet.

[0022] Optionally, requesting a time-limited encryption key may comprise generating request data including data representative of the user controlled device and control unit to which the command data packet is required to be sent, and transmitting the request data to the remote key issuing platform.

[0023] In one embodiment, constructing the command data packet comprises:

[0024] - constructing a plain value data package comprising the command data and a number of attributes associated therewith, generating a signature for the number of plain value attributes, and appending the signature to the plain value data package to generate a signed data package;

[0025] - encrypting the signed data package using the timed encryption key to generate an encrypted command payload;

[0026] - appending the encrypted command payload to the plain value header.

[0027] The plain value header may include data representing a command time extracted from a real-time clock of the user controlled device and an owner ID representing a user of the user controlled device.

[0028] According to another aspect of the invention, there is provided a computer implemented method executed on a control unit including a security module and a control processor for receiving, validating and implementing valid command data received from a user controlled device, the security module having a plurality of base keys stored therein, the method comprising, under control of the processor of the security module:

[0029] receiving a command data packet from a user control device, the command data packet including a plain value header and an encrypted command payload, the command payload including command data encrypted by at least a time-limited encryption key, the plain value header including:

[0030] data representing the subset of the attributes of the command data, excluding a particular attribute or attributes used by a key issuing platform to select a base key from which the encryption key is generated;

[0031] receiving, including the checksum value;

[0032] - determining the one or more particular attributes using attribute data contained in the plain value header and the checksum value;

[0033] - selecting a base key from the stored base keys associated with the particular attribute or attributes;

[0034] - calculating the encryption key using the selected base key;

[0035] - decrypting the command payload, including the command data, using the encryption key;

[0036] - transferring the decoded command data to the control processor.

[0037] In one embodiment, the method may further comprise calculating the encryption key using the selected base key and the checksum value.

[0038] The plain value header may include data representing the expiration date and / or time of a key associated with the command data packet, and the method further comprises checking the expiration date of the key against a date and / or time maintained in a real-time clock of the security module.

[0039] In one embodiment, one of the command data attributes may be a command time and data representing same may be included in a plain value header of a command data packet, and the method may further comprise comparing the command time to previously stored command times and / or a time held by a real time clock of the control unit to determine whether a command time is valid and, if not, discarding the command data packet.

[0040] According to a further aspect of the invention, there is provided a computer implemented method executed on a key issuing platform for generating a timed encryption key for use by one or more remote user controlled devices for one or more control units, the method comprising:

[0041] - receiving a request for a timed encryption key from a remote user controlled device, the request including data representative of the user controlled device and a control unit to which the user controlled device wishes to issue a command;

[0042] - determining one or more specific command data attributes and selecting, from a set of stored base keys, a base key that corresponds to said one or more specific command data attributes;

[0043] - calculating a checksum value representing at least a subset of the command data attributes including the particular command data attribute or attributes used to select a base key;

[0044] - calculating an encryption key using the selected base key;

[0045] - transmitting the encryption key to the user control device together with the checksum value and data representing the expiration date of the key.

[0046] In one embodiment, an encryption key may be calculated using the base key and the checksum value.

[0047] According to another aspect of the present invention, there is provided a computer implemented security module for integration onto a control unit chip, the security module having a processor and memory and a plurality of stored base keys, the security module executing instructions stored in the memory under control of the processor to:

[0048] receiving a command data packet from a user control device, the command data packet including a plain value header and an encrypted command payload, the command payload including command data encrypted by at least a time-limited encryption key, the plain value header including:

[0049] data representing the subset of the attributes of the command data, excluding a particular attribute or attributes used by a key issuing platform to select a base key from which the encryption key is generated;

[0050] receiving, including the checksum value;

[0051] - determining the one or more particular attributes using attribute data contained in the plain value header and the checksum value;

[0052] - selecting a base key from the stored base keys associated with the particular attribute or attributes;

[0053] - calculating the encryption key using the selected base key;

[0054] - decrypting the command payload, including the command data, using the encryption key;

[0055] - transferring the decoded command data to a control processor of a control unit.

[0056] Another aspect of the invention provides a computer implemented control unit comprising an integrated circuit having a control processor and a security module, the security module having a processor, a memory, and a plurality of stored base keys, and executing instructions stored in the memory under control of the processor to:

[0057] receiving a command data packet from a user control device, the command data packet including a plain value header and an encrypted command payload, the command payload including command data encrypted by at least a time-limited encryption key, the plain value header including:

[0058] data representing the subset of the attributes of the command data, excluding the particular attribute or attributes used by a key issuing platform to select a base key from which the encryption key is generated;

[0059] receiving, including the checksum value;

[0060] - determining the one or more particular attributes using attribute data contained in the plain value header and the checksum value;

[0061] - selecting a base key from the stored base keys associated with the particular attribute or attributes;

[0062] - calculating the encryption key using the selected base key;

[0063] - decrypting the command payload, including the command data, using the encryption key;

[0064] - transferring the decoded command data to the control processor.

[0065] Yet another aspect of the present invention is a method for implementing a method for testing a computer comprising: a processor and a memory, and executing instructions stored in the memory under control of the processor,

[0066] - requesting a timed encryption key from a remote key issuing platform and receiving the timed encryption key from the key issuing platform, the timed encryption key being generated by the key issuing platform using a base key selected according to a particular one or more of the attributes associated with the command data;

[0067] receiving from the key issuing platform, together with the timed encryption key, a checksum value representing at least a subset of the attributes of the command data, including the particular attribute or attributes used by the key issuing platform to select a base key;

[0068] - encrypting at least said command data using said timed encryption key;

[0069] constructing a command data packet comprising a plain value header and an encrypted command payload, the plain value header comprising:

[0070] data representing the subset of the attributes of the command data, excluding a particular attribute or attributes used by a key issuing platform to select the base key;

[0071] the checksum value;

[0072] the command payload comprises at least the encrypted command data;

[0073] To build and

[0074] - transmitting said command data packet to said control unit.

[0075] According to a further aspect of the present invention, there is provided a method for implementing a method for storing a program for performing a program on a computer, the method comprising:

[0076] - receiving a request for a timed encryption key from a remote user controlled device, the request including data representative of the user controlled device and a control unit to which the user controlled device wishes to issue a command;

[0077] - determining one or more specific command data attributes and selecting, from a set of stored base keys, a base key that corresponds to said one or more specific command data attributes;

[0078] - calculating a checksum value representing at least a subset of the command data attributes including the particular command data attribute or attributes used to select a base key;

[0079] - calculating an encryption key using the selected base key;

[0080] - transmitting the encryption key to the user controlled device together with the checksum value and data representing an expiration date of the key.

[0081] An aspect of the invention extends to a computer program product comprising instructions for performing the method substantially as described above.

[0082] Another aspect of the invention extends to a computer program comprising instructions for performing the method substantially as described above.

[0083] Another aspect of the invention extends to a non-transitory storage medium storing instructions which, when executed by a processor, cause the processor to perform a method substantially as described above.

[0084] According to yet another aspect of the present invention, there is provided a communication system comprising a client device, a server, and a key issuing platform, the server having an integrated security module, the client device being communicatively connectable to the server via a designated communication link, the client device having an input for receiving an encryption key from the key issuing platform via said communication network, an output for sending an encryption key request to the key issuing platform, and an output for sending a command data packet to said server;

[0085] The key issuing platform, under the control of the processor, executes instructions in the memory to

[0086] receiving a request for a timed encryption key from the client device, the request including data representative of the client device and a server to which the client device wishes to issue a command;

[0087] - determining one or more specific command data attributes and selecting, from a set of stored base keys, a base key that corresponds to said one or more specific command data attributes;

[0088] - calculating a checksum value representing at least a subset of the command data attributes including the particular command data attribute or attributes used to select the base key;

[0089] - calculating an encryption key using the selected base key;

[0090] - transmitting the encryption key to the client device together with the checksum value and data representative of the expiration date of the key;

[0091] The client device executes instructions under the control of the processor to

[0092] receiving from the key issuing platform, together with the timed encryption key, a checksum value representing at least a subset of the attributes of the command data, including the particular attribute or attributes used by the key issuing platform to select a base key;

[0093] - encrypting at least said command data using said timed encryption key;

[0094] constructing a command data packet comprising a plain value header and an encrypted command payload, the plain value header comprising:

[0095] data representing the subset of the attributes of the command data, excluding the particular attribute or attributes used by a key issuing platform to select a base key;

[0096] the checksum value;

[0097] the command payload comprises at least encrypted command data;

[0098] To build and

[0099] - transmitting the command data to the server;

[0100] The server is configured to forward the received command data packets to the security module, which executes instructions in the memory under control of a processor to:

[0101] receiving a command data packet from a client device, the command data packet including a plain value header and an encrypted command payload, the command payload including command data encrypted by at least a time-limited encryption key, the plain value header including:

[0102] data representing the subset of the attributes of the command data, excluding the particular attribute or attributes used by a key issuing platform to select a base key from which the encryption key is generated;

[0103] receiving, including the checksum value;

[0104] - determining the one or more particular attributes using attribute data contained in the plain value header and the checksum value;

[0105] - selecting a base key from the stored base keys associated with the particular attribute or attributes;

[0106] - calculating the encryption key using the selected base key;

[0107] - decrypting the command payload, including the command data, using the encryption key;

[0108] - transferring the decoded command data to a control processor of a server.

[0109] As will become apparent below, aspects of the present invention can provide security methods, devices, and protocols that can be configured to identify commands from an unlimited number of user-controlled devices, each of which may have different permissions and / or access levels for different time periods, without requiring network connectivity to operate, without relying on another service for certificate validation or certificate storage, and commands can be processed in real-time. Thus, security modules according to exemplary embodiments of the present invention operate offline, accommodate an unlimited number of unknown users, require low power and storage overhead, do not require sharing of keys with third parties, and do not require default passwords. These and other aspects of the present invention will become apparent from the detailed description that follows. [Brief description of the drawings]

[0110] Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Figure 1] FIG. 1 is a schematic block diagram illustrating a communication system including a server or MCU / MPU device with an integrated security module according to an exemplary embodiment of the present invention. [Diagram 2] FIG. 1 is a schematic block diagram illustrating a control system including an MCU / MPU device with an integrated security module, in accordance with an exemplary embodiment of the present invention. [Diagram 3] A schematic process diagram showing the main steps of an exemplary method performed on a user-controlled device within a control system such as that shown generally in FIG. 2. [Figure 4] FIG. 3 is a schematic process diagram illustrating the main steps of an exemplary method performed in an integrated security module of an MCU / MPU device in a control system such as that shown generally in FIG. 2. [Figure 5A] FIG. 2 is a schematic diagram illustrating an exemplary process in a key issuing platform, according to an exemplary embodiment of the present invention. [Figure 5B]A schematic diagram showing an exemplary process in a user control device according to an exemplary embodiment of the present invention. [Figure 5C] FIG. 2 is a schematic diagram illustrating an exemplary process in a security module, according to an exemplary embodiment of the present invention. [Figure 6A] FIG. 5B is a schematic diagram showing data transformations associated with the process of FIG. 5A. [Figure 6B] FIG. 5C is a schematic diagram illustrating the data transformations associated with the process of FIG. 5B. [Figure 6C] FIG. 5D is a schematic diagram illustrating data transformations associated with the process of FIG. 5C. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0111] A microcontroller or MCU is an integrated circuit that consists of a processor unit, a memory module, a communication interface, and peripherals. As will be apparent to those skilled in the art, the biggest difference between an MCU and a microprocessor (along with the peripherals required to operate) is that an MCU is designed to be as small and use as little power as possible, and is typically dedicated to a single function and is most often embedded in other devices (e.g., consumer electronics). This therefore keeps the cost and complexity of the product in which it is embedded as low as possible. MCUs are used in a wide range of applications, including washing machines, robots, drones, radio and game controllers, and all kinds of IoT devices.

[0112] The drawback of MCUs is, of course, their inherent lack of security. Typically, MCUs are dedicated to a single function and are intended to consume as little power as possible, so they are often designed to remain offline unless they need to be connected for some special reason (e.g., for remote maintenance). The complete device, including all necessary RAM, ROM, and peripherals, is provided on a single small (low-power) microchip, and this is possible because they only have the limited functionality required for the current application and (in many cases) nothing more. Thus, there is often no security associated with MCUs, which is becoming increasingly problematic. An IoT device connected to a WiFi router in a home (for example) poses a risk to the network (and all other devices connected to that network in the home) by opening up the possibility of attacks by malware and viruses that have entered the network through the IoT device, potentially stealing or corrupting data from any other devices connected to it. On the other hand, it is difficult to install and run protective software such as a firewall on the processor of an MCU without losing the low-cost, low-power factor that makes it attractive in the first place.

[0113] Prior art security protocols aimed at protecting computing devices from such attacks often require Internet access to function correctly whenever a command message is received, which can significantly increase power consumption. Such protocols may also require storage of a user key, which increases the storage overhead (and size) of the device and limits the number of clients that can communicate with the device. This also requires that the client device be pre-known to the server device in order to first store the client device's key, and therefore does not support the use of client devices that are not pre-known, especially without Internet access and significant processing overhead. The method and apparatus described below address these technical challenges and provide a secure communication method and communication security module that allows an MCU to receive and process command messages from pre-unknown (but authorized) client devices without the need to store individual client device or user keys and without increasing the MCU's processing overhead or power consumption, while blocking unauthorized data packets without requiring Internet access (such data packets can be transmitted by any known communication means, as will be described in more detail below).

[0114] Referring to Figure 1 of the drawings, a communication system is shown. The communication system 100 comprises a control unit in the form of a microcontroller unit (MCU) or microprocessor unit (MPU) 104, a key issuing platform (KIP) 106, and a user control device 102. During manufacture of the PCU / MPU device 104, the PCU / MPU device 104 and the key issuing platform 106 are communicatively coupled over a communication network 108 (e.g., the Internet) through respective communication links 110, 114 implementing, for example, the Internet communication protocol. The MCU / MPU device 104 and the KIP 106 may be communicatively coupled over other communication networks, such as the Public Switched Telephone Network (PSTN), including mobile cellular communication networks, but are omitted from Figure 1 for clarity. It will be appreciated that after manufacture and configuration of the MCU / MPU device 104, the MCU / MPU device 104 and the KIP 106 do not need to communicate further, except in situations where encryption keys need to be updated. The user controlled device 102 can communicate with the MCU / MPU device 104 via a communication link 111 implementing any number of different communication protocols, including (but by no means limited to) Bluetooth, HTTP, UART, SERIAL, etc., or via a communication link 112 implementing, for example, an Internet communication protocol, although the invention is by no means intended to be limited in this respect. Indeed, as will be described below, the user controlled device(s) can be configured to communicate with the MCU / MPU device 104 via a communication protocol appropriate for the application, without either device needing a connection to the communication network 108 to send, receive, and validate command data packets, which is in fact one of the key technical advantages of embodiments of the invention. The MCU / MPU device 104 does not require an Internet connection to receive or validate command data packets from the user controlled device 102 and act upon them, meaning that additional power consumption is minimized and security is improved, making some embodiments of the invention particularly well suited for IoT devices.The user controlled device 102 can communicate with the KIP 106 over a communications network 108, such as the Internet, via a communications link 110 that implements, for example, the Internet Communications Protocol.

[0115] In the example of FIG. 1, the MCU / MPU device 104 may comprise several distinct components, including, but not limited to, one or more microprocessors 116 and a memory 118 (e.g., volatile memory such as RAM) for loading executable instructions 120 that define the functionality that the MCU / MPU executes under the control of the processor 116. The MCU / MPU device 104 also comprises an input / output module 122 that enables the MCU / MPU device 104 to communicate with the user control device 102 via one of several (typically, but not essentially short-range) communication protocols. A user interface 124 is provided for user control and may comprise computing peripherals such as, for example, a display screen, a touch screen, a keypad, or a monitor, a mouse-type input device, or a computer keyboard. The functionality of the user interface 124 and the peripherals required will depend on the application in which the MCU / MPU device 104 is being utilized, and the invention is not intended to be necessarily limiting in this respect.

[0116] The user control device 102 may comprise several distinct components, including, but not limited to, one or more microprocessors 128 and memory 130 (e.g., volatile memory such as RAM) for loading executable instructions 132, which define the functionality that the user control device 102 executes under the control of the processor 128. The user control device 102 also comprises an input / output module 134 that allows the user control device 102 to communicate over the communications network 108 and also over other communications protocols (if so configured). A user interface 136 is provided for user control. If the user control device 102 is, for example, a smartphone or tablet device, the user interface 136 will likely have a touch panel display as is common in many smartphones and other handheld devices. Alternatively, the user control device may comprise a keypad, keyboard, computer mouse, or the like, to allow the user to input control data. The MCU / MPU device further comprises a security module 148 , which is integrated on the same integrated circuit as the other MCU / MPU device components and is communicatively coupled to the processor 116 .

[0117] The key issuing platform (KIP) 106 may comprise several distinct components including, but not limited to, one or more microprocessors 138 and a memory 140 (e.g., volatile memory such as RAM) for loading executable instructions 142, which define the functionality that the KIP 106 performs under the control of the processor 138. The KIP 106 also comprises an input / output module (which may include a transceiver module) 144 that enables the KIP 106 to communicate over the communications network 108. In some circumstances, a user interface 146 may be provided for user control by any known input means.

[0118] The MCU / MPU device 104 includes an integrated security module 148 to which the main MCU / MPU is communicatively coupled, as described in more detail below.

[0119] Referring to FIG. 2 of the drawings, a communications security module 148 is integrated into the MCU / MPU device 104 and includes a real-time clock 149 that is used to generate timed encryption keys and to validate incoming data packets (also referred to herein as command data packets).

[0120] The communications security module 148 (also referred to herein simply as security module 148) has multiple (n) base encryption keys that are used to generate timed encryption keys that are used to decrypt and verify command payloads of command data packets received from the user control device 102.

[0121] The KIP 106 is physically separate from the MCU / MPU device 104 (including the integrated security module 148) and has the same n base encryption keys as the security module 148, and a real-time clock 107. The base encryption key held by the KIP 106 is used to generate a timed encryption key used by the user device 102 to encrypt and sign data it sends to the MCU / MPU device 104. The encrypted data packet comprises a plain value header and a command payload comprising data encrypted using the timed encryption key provided by the KIP 106, as described in more detail below. However, it is important to note that the plain value data provided in the header is sufficient for the security module 148 of the MCU / MPU device 104 to determine the timed encryption key used to encrypt the command message, thus enabling it to decrypt the message with the plain value data and return the plain value data to the MCU / MPU for processing and operation. The security module 148 does not require communication with the KIP 106 during the verification and decryption process, which means that the additional power consumption overhead of a security module 148 integrated into the MCU / MPU device 104 is negligible and also means that the present invention can be used in applications where the MCU / MPU device is rarely actually connected to the Internet, making it ideal for use in IoT devices, vehicle security entrance security, etc.

[0122] Referring to FIG. 3 of the drawings, an overview of the first part of an exemplary process is shown, where in step 300, the user controlled device 102 wishes to send a command message to the MCU / MPU device 104 and therefore sends a request for an encryption key to the KIP 106 (e.g., via the communication network 108). In response to the request, the KIP generates a time-limited encryption key specific to the command type or access level granted by the user controlled device. In practice, a base key is selected from n base keys held by the KIP 106 based on the access level granted by the user, which is based on the user data held by the KIP 106. The access level may also define the period during which the encryption key is valid, allowing the KIP to calculate the expiration date of the key. Once the user data is verified and the access level is determined, a base key is selected and an encryption key may be generated, for example, by performing a keyed hash function on the base key and selected data associated with the user and the command message the user wishes to send, as described below.

[0123] More specifically, the encryption key is generated by performing a keyed hash function on a checksum derived from a combination of a selected base key and a number of different values ​​associated with the command message. In an exemplary embodiment, the checksum may be an arithmetic sum of a number of such values. One of these values ​​is data representative of the access level (or the access level number itself). Others of these values ​​may include data representative of the user, data representative of the MCU / MPU device to which the command message is to be sent, and / or a key expiration date (or data representative thereof). In some cases, only one or two of the latter values ​​may be used, which would reduce the level of security provided by this example. Additional data items may also be included, which would increase security but also increase complexity and processing overhead.

[0124] In one example, the user ID, (MCU / MPU) device ID, access level number and key expiration date are arithmetically summed to generate a checksum, and the encryption key is generated by KIP 106 by running a cryptographic algorithm, such as a keyed hash function, on a base key (selected according to the user's access level) and the checksum.

[0125] It is contemplated that the checksum can be calculated using different equations or algorithms and that different data can be used for it, however the following important factors are:

[0126] · The security module 148 must know how the checksum was calculated;

[0127] The security module must know the criteria by which the base key is selected; and

[0128] The checksum should include data representing the criteria by which the base key was selected. So in this example, the base key is selected depending on the access level. So the data representing the access level is included in the checksum. However, if the base encryption key is selected based on other criteria, for example command type, then data representing that should be included in the checksum calculation.

[0129] In this example, the checksum is generated using the arithmetic sum of the various identifying data, which is considered to be one of the simplest options, but other equations and algorithms are also possible, as long as the security module knows what they are.

[0130] Returning to FIG. 3 of the drawings, in step 302, the security module 150 of the user control device 102 receives the encryption key. In step 304, the user control device encrypts the command message using an appropriate encryption algorithm and encryption key as known to those skilled in the art. Then, in step 306, the user control device 102 constructs a plain value header. The plain value header should contain sufficient data to enable the security module 148 to determine how the base encryption key was selected by the KIP 106, so that the security module 148 can select the same base encryption key from its own store, recreate the encryption key, and therefore decrypt the command message. Thus, in one example, the plain value header may include data items representing all values ​​used to generate the checksum, except for a value indicating how the base encryption key was selected, and also data identifying the checksum itself. In one example, the plain value header includes data representing the key expiration time and the time the command was generated (CommandTime) so that some initial validation checks can be performed by security module 148 when it receives the command message (command data packet) using its own real-time clock 149, as described in more detail below. In some examples, the command data may be signed before it is encrypted so that the final encrypted command data includes a cryptographic signature that validates the command data to which it is attached.

[0131] In step 308, the user control device appends the encrypted command data to a plain value header to construct a command data packet, and in step 310, the user control device sends the command data packet to the MCU / MPU device 104.

[0132] It will be appreciated that while an on-chip security module 148 is used in conjunction with the MCU / MPU device 104 to ensure that there is no undetected tampering with the communication between the security module and the processor 116, no such dedicated module is required in the user control device 102. The key request and command data packet construction process can be implemented within an app or other software module running on the user control device. In many applications, the key request and command data packet construction process can be implemented in a downloadable app configured to communicate with one or more associated controllers. Given that both the KIP and the security module have access to the same set of base keys and rules for selecting base keys and generating encryption keys, as exemplified below, the present invention can be implemented in many different ways for many different applications.

[0133] Referring to FIG. 4 of the drawings, in step 400 , the MCU / MPU device 104 receives the command data packet at its input / output module 122 and immediately forwards it to the security module 148 .

[0134] In step 402, the security module uses the plain value header to perform some initial validation checks on the command message, particularly the key expiration date and the time the command was generated. The security module compares the key expiration date to a date kept by its real-time clock 149, and if it determines that the key has expired, the security module discards the data packet. Similarly, if the CommandTime is later than the current time kept in the clock 149, or is outside a range of a few seconds earlier than the current time, the packet is discarded. If the received command data packet passes these initial validation checks, the process proceeds to step 404, where the checksum is reversed. The checksum (or data representing the checksum) and all but one of the data used to calculate the checksum are included in the header. The remaining value, i.e., the value used to determine the base key used to generate the encryption key, is the only part that is missing. There are several ways to reverse the equation or algorithm to identify the missing data. In one example, the missing data can be an access level defined in terms of a set of integers 1 to x, for example, in ascending order. Each access level may represent the degree of control a specified user has over the MU / MPU device. For example, if the MCU / MPU device is configured to control room usage, access level 1 may represent light and door control, access level 2 may define door control only, access level 3 may define lights only, access level 4 may define all room functions and reservation permissions, etc. In this case, the security module may be configured to simply perform a checksum calculation multiple times using data known to the security module and an integer from 1 to x, incrementing that integer through each iteration until the resulting checksum matches the checksum identified in the header.

[0135] In step 406, once data defining the selection of a base key is identified from a matching checksum calculation, that base key may be selected by the security module 148 from its own store of base keys and used to generate an encryption key in the same manner as was generated by the KIP 106 for the user controlled device 102.

[0136] In step 408, the security module decrypts the command message. It is assumed that the command message contains not only the command itself, but also some data bytes that can be used to further validate the command message. For example, the command message may contain data indicating the character length of the command itself, and may also contain a CommandTime and data about the user (i.e., OwnerID). If so, when the command message is decrypted, the security module 148 may be configured to perform further validation on this additional data. For example, if the OwnerID does not match the OwnerID in the header, the packet is discarded. If the CommandTime of the command message does not match the CommandTime in the header, the packet is discarded. If a signature is present in the command message, it may be recomputed and the result is checked against the signature in the decrypted command message, and if they do not match, the packet is discarded.

[0137] Upon successful completion of these additional validations, the security module may be configured to concatenate only the CommandTime and the decoded CommandData itself, in step 412, and send the concatenated data to the MCU / MPU for processing and action.

[0138] Now, referring to Figures 5A, 5B and 5C of the drawings, we will put all the above examples and embodiments together and describe a complete process example in more detail. The process starts when the user controlled device 102 (which may not be known in advance to the MCU / MPU device 104) generates request data requesting a new key to be able to issue a command to the MCU / MPU 104 to make it perform a specific task. The request data sent by the user controlled device 102 to the key issuing platform (KIP) 106 includes (at least) an OwnerID (comprising an identifier (e.g., number) uniquely associated with the user (or the user's device)) and a DeviceID (comprising an identifier (e.g., number) uniquely associated with the MCU / MPU device to which the command is issued). In one example, the OwnerID may be a four digit number unique to the user, such as "1001," and the DeviceID may be a six digit number unique to the MCU / MPU device 104, such as "220280," although the invention is by no means limited in this respect. The request data is transmitted to the KIP 106 via the communications network 108.

[0139] As explained above, KIP 106 first checks the user's credentials to verify that they are authorized to issue such commands to MCU / MPU device 104. The user may be required to pre-register with a service associated with MCU / MPU device 104 in order to obtain a key to access MCU / MPU device 104, and the level of such registration may define the types of tasks the user is authorized to have MCU / MPU device 104 perform.

[0140] Both the KIP 106 and the MCU / MPU device 104 have a number (n) of base encryption keys. The base encryption keys in this example are simple relatively short alphanumeric code words that can be used as longer encryption keys during the process. The multiple base encryption keys are hierarchically labeled with AccessLevel or permissions, with each base key associated with a different access level (to the MCU / MPU device 104), with each AccessLevel being represented in this example by a respective integer from 1 to x. Thus, each base encryption key is associated with a respective Command ID Group, whereby each Command ID Group identifies the set of commands that can be processed (by the MCU / MPU device 104) with the base key for that permission level. Once the KIP 106 determines that the user (defined by the OwnerID data in the encryption key request) is authorized to issue commands to the MCU / MPU device 104, it looks up the access permission level (AccessLevel) for that user and the time period for which the encryption key should be valid (KeyValidFor). It also looks up the base key for the Command ID Group linked to the user's AccessLevel, step 502. Thus, it should be apparent that an AccessLevel identifier (eg, "1") defines a base encryption key (eg, "BaseKey1") that is used to generate encryption keys.

[0141] So in a simple example, BaseKey1 is the base encryption key linked to AccessLevel1, where BaseKey1="ABCD", BaseKey2 is the base encryption key linked to AccessLevel2, where BaseKey2="EFGH", and BaseKey3 is the base encryption key linked to AccessLevel3, where BaseKey3="IJKL". The BaseKeys and associated AccessLevels are stored in the security modules of KIP 106 and MCU / MPU device 104.

[0142] After KIP 106 validates the user, their AccessLevel, and the period for which the associated key should be valid (KeyValidForDays), it retrieves the base key linked to that AccessLevel from the set of base encryption keys (step 502). Thus, in one example, a new user is verified and determined to have the authorization corresponding to AccessLevel1, which makes the key valid for 30 days. KIP 106 retrieves BaseKey1 ("ABCD").

[0143] In step 504, the KIP 106 calculates the expiration date of the key.

[0144] (Number 1) KeyExpDate = current date (derived from RTC107 in KIP106) + KeyValidForDays YYYYMMDD+30 For example, 20210130+30 KeyExpDate=20210301

[0145] Next, in step 506, a value known herein as a "CheckSum" is calculated that essentially combines several key data derived from the request data to generate a single data item (in this case a number) that represents the combination of the key data. In one example, the key data consists of DeviceID, KeyExpDate, AccessLevel, and OwnerID, and in one example, this key data, which is all numeric, is arithmetically summed (i.e., simply added) to generate a new number that represents the combination of all the key data. For example,

[0146] (Number 2) Checksum=DeviceID+KeyExpDate+AccessLevel+OwnerID For example, 220280+20210301+1+1001 Checksum=20431442

[0147] Finally, in step 508, the KIP 108 calculates a new encryption key for the user controlled device 102. Because the AccessLevel is "1", BaseKey1 is selected (e.g., "ABCD" referenced above). The new encryption key is generated using a cryptographic algorithm applied to the above checksum and the selected base encryption key. In one example, a keyed hash algorithm may be used. In a specific example, the HMACSHA256 algorithm may be used. HMACSHA256 is a keyed hash algorithm well known to those skilled in the art and commonly used in the field of cryptography as a hash-based message authentication code. Other suitable HMAC implementations include HMACMD5 and HMACSHA1, as well as others known to those skilled in the art. In this specific example, the HMACSHA256 algorithm is used, although the invention is in no way intended to be limited in this respect.

[0148] Still referring to FIG. 6A, in step 508, KIP 106 converts the BaseKey “ABCD” and the checksum into a new (secret) encryption key (EncKey) unique to the user controlled device request by applying the HMACSHA256 encryption algorithm to the selected BaseKey and the calculated checksum as follows: JPEG2024528971000002.jpg55166

[0149] KIP 106 then transmits the calculated EncKey, along with data representing the checksum and KeyExpDate, to the user control device 102 via communications network 208, and the EncKey data, along with the checksum and KeyExpDate data, is received by the user control device 102 and stored (if not immediately) until command data needs to be sent to the MCU / MPU device 104.

[0150] The encryption key is retrieved and used when the user control device wishes to send command data to the MCU / MPU device 104. For example, if the MCU / MPU device 104 is an electronic door access control device with the ability to selectively unlock a door in response to a valid command message from the user control device, the command data that needs to be sent by the user control device 102 may be "OPEN", although this element will vary greatly depending on the application and the present invention is in no way intended to be limiting in this respect. However, merely by way of example and to aid in understanding, a command packet sent by the user control device 102 to execute the command data "OPEN" may have the following attributes: CommandTime (i.e., the time the command packet is generated, obtained from the real-time clock 103): YYYYMMDD HH:MM; for example, 20210222 12:30 CommandID (a unique identifier associated with this command): e.g., 2000 CommandData For example, "OPEN" EncryptionIV For example, 1234567890123456

[0151] As is well known to those skilled in the art, EncryptionIV is an encryption initialization vector, which is simply a random, or at least unique, input to a cryptographic algorithm (i.e., the cryptographic algorithm used to encrypt the command message) to provide an initial state.

[0152] Referring now to FIG. 5B of the drawings, in step 510, the user control device 102 arithmetically sums CommandData, OwnerID, CommandTime, CommandLength, and CommandID, and in step 512 uses the result to generate a cryptographic signature (thereby effectively "signing" the sum of these attributes and data items). The cryptographic signature is generated by using a keyed hash algorithm (e.g., SHA256, although other algorithms are known to those skilled in the art) on the sum. Thus, still referring to FIG. 6B of the drawings, the user control device first builds a data package comprising the values ​​of CommandData, OwnerID, CommandTime, CommandLength, and CommandID, as referenced above. It then signs the sum of these data to create a signature block (step 514) and appends the signature block to the data package.

[0153] In step 516, the data package including the signature block is encrypted to generate the command body (or command data packet payload). Any known encryption method can be used at this stage. For example, the AES encryption method is well known to those skilled in the art and will not be described in detail herein for clarity. In the illustrated example, the encryption key (EncKey) received from KIP 106 and the encryption initialization vector EncryptionIV described above are used to generate the command body (or command data packet payload).

[0154] (Number 4) OwnerID+CommandTime+CommandLength+CommandID+CommandData+Signature

[0155] Suffice it to say that the AES encryption method is performed on the concatenation of the following, resulting in the following command payload:

[0156] UjtLqGk75mLmdQVuisbFsYCofq+0TIcD3Ovgyzr2g8XgwYTM06qUbwJN00SaATvYMOvDX8X9aLiKcj34+v / 3cpwYTie+SMKqgv2JR7vlE8YnkPbeUX4Ga+MyffF / IJGf

[0157] is appended (at step 516) to the plain value (unencrypted header) to construct a command data packet, as shown in Figure 6B. The plain value header consists of the key expiration date (KeyExpDate) (received along with the encryption key from KIP 106), the CommandTime determined at step 510, a user specific and unique OwnerID, a Checksum (calculated by KIP 106 at step 506 of the encryption key generation process and provided to the user controlled device along with the encryption key), and the CommandID obtained at step 510.

[0158] The command data packets are sent to the MCU / MPU device 104 and received at its input 122 (FIG. 1). It should be understood that the command data packets can be sent to the MCU / MPU device 104 via any communication policy implemented in the application. Thus, for example, the user-controlled device 102 and the MCU / MPU device 104 can be configured to communicate with each other via protocols such as Bluetooth, WiFi, Ethernet, USB, UART, SERIAL, etc., and the present invention is not necessarily intended to be limited in this respect. Indeed, one of the main technical advantages of the present invention is that the MCU / MPU device 104 including the security module 148 does not need to be connected to the Internet (or other communication network 108) to receive and verify data packets from an unknown user-controlled device 102. Thus, the command data packets received at the input 122 of the MCU / MPU device 104 are directly forwarded to the on-chip integrated security module 148.

[0159] 5C of the drawings, in the security module 148, when a command data packet is received, an initial verification process is performed in step 518 on the plain values ​​contained in the (unencrypted) header. The security model 148 uses its real-time clock 149 to determine the current date and time. The KeyExpDate is then first compared to the current date, and if it has expired the command data packet is discarded. If it has not expired, the CommandTime is checked. If the CommandTime is earlier than the CommandTime of the last command data packet received, or is more than a few seconds from the time kept by the real-time clock 149, the command data packet is discarded. Otherwise, if these verifications are completed successfully, the process proceeds to step 520.

[0160] In step 520, the security module 148 calculates a checksum, thereby determining the encryption key used to encrypt the command payload. The security module derives from the plain value header data:

[0161] OwnerID+KeyExpDate can be determined.

[0162] The DeviceID is a unique identifier associated with the MCU / MPU device 104 in which the security module 148 is integrated, and is therefore known to the security module 148. The plain value header also contains a checksum value. Thus, at this stage, the security module 148 has

[0163] (Number 5) OwnerID+DeviceID+KeyExpDate+[unknown]AccessLevel=Checksum is known.

[0164] From this, it is clear that the AccessLevel can be determined. In one example, the security module cycles through AccessLevel=1 to x (where x is the highest AccessLevel associated with the BaseKey stored by both the KIP 106 and the security module 148 of the MCU / MPU device 104). At each iteration of the checksum calculation, the security module 148 checks to see if the result matches the checksum value in the command data packet header. If there is no match, it increments the AccessLevel value by 1 and repeats the checksum calculation until all possible values ​​of AccessLevel have been tried and no match is found (in which case the command data packet is discarded) or a match is determined and the AccessLevel number is found.

[0165] Once the AccessLevel number is known, the associated BaseKey can be retrieved (at step 522) and the encryption key used to encrypt the command data packet payload is determined in the manner described above, i.e.

[0166] (Number 6) This can be calculated (in step 523) as HMACSHA256(BaseKey, Checksum)=EncKey.

[0167] Then, in step 524, the command packet payload is decrypted using the EncKey thus calculated (the same EncKey provided to the user control device 102 by KIP 106 at the start of the process).

[0168] With further reference to FIG. 6C, the now decrypted command data packet payload comprises the OwnerID, CommandTime, CommandLength, CommandID, CommandData and Signature, similar to the unencrypted command payload shown generally in FIG. 6B.

[0169] In step 526, a validation process is performed on the decoded command payload. First, the OwnerID in the decoded command payload is checked against the OwnerID in the plain value header. If there is no match, the command data packet is discarded. Also, the CommandTime in the decoded command payload is checked against the CommandTime in the plain value header, and again if there is no match, the command data packet is discarded.

[0170] The signature is then calculated as described above with respect to step 512 of FIG. 5B.

[0171] SHA256(OwnerID, CommandTime, CommandLength, CommandID, CommandData)

[0172] Here, OwnerID, CommandTime, CommandLength, CommandID, and CommandData are all obtained from the decrypted command payload. If the signature does not match the signature in the decrypted command payload, the command data packet is discarded. On the other hand, if there is a match at this stage, the command data packet is decrypted and fully verified.

[0173] The CommandTime is stored by the security module 148 of the MCU / MPU device 104 to prevent replay attacks and also to be used to validate future command data packets (step 518, FIG. 5C).

[0174] In step 528, the CommandID and CommandData are extracted from the decoded command payload and concatenated, and the result is returned to the MCU / MPU 116 for processing and action. In this example, the data returned to the processor 116 is:

[0175] (Number 7) CommandID=2000

[0176] (Number 8) CommandData=OPEN

[0177] In some examples, for added security, the security module 148 may hold a counterpart key to the EncKey. In this case, as explained above, once the Command Data packet is decrypted and fully verified, the security module 148 checks whether it holds a counterpart key to the EncKey, and if not, proceeds to step 528. However, as explained above, even if the security module 148 does have a counterpart key, the security module 148 still extracts and concatenates the CommandID and CommandData, but the security module 148 signs the concatenated data before sending it to the processor 116, and adds a signature to the (unencrypted) data before sending it to the processor 116, as shown diagrammatically in FIG. 6C. This last step is a way for the processor to verify that the data packet has been processed and verified by the security module 148. However, this is by no means required, and simply adds an additional layer of security to the process if required in some applications.

[0178] It will be apparent from the foregoing that the method and apparatus of the present invention can be used in a variety of different applications, too numerous to list here, although for completeness two potential applications are described below.

[0179] In a first application example, the MCU / MPU device is integrated into a control system configured to control the door locks and lighting of a sports hall (e.g., a squash court) that can be booked and used 24 / 7. The booking system is automated and provided by an app on a user's smartphone or other handheld computing device. The controller of the control system is configured to unlock the electronic door lock and turn on the lights in response to command data "OPEN". Alternatively, two separate control systems may be provided, each performing separate functions: a first function to unlock the door, and a second function to turn on the lights. The MCU controlling the lights keeps the lights on for a predefined period, e.g., one hour, and automatically turns them off when the timer expires, ready for the next user. The sports hall may be too far from the main building, so the control system(s) cannot access the sports club's WiFi, and instead may be configured to communicate with the user device via a short-range communication protocol such as Bluetooth.

[0180] When a user wants to book a time slot at a sports hall, they use an app on their handheld device to select a court and an available time slot. The app is configured to obtain an encryption key from the KIP in the manner explained above and store it for future use. The encryption key is time-limited in the sense that it is only valid for the date / time slot booked by the user. Therefore the value of KeyValidFor is set accordingly.

[0181] When the user arrives at the sports hall premises, they open the app, select the booked sports hall or time slot, press the "button" and a command data packet is sent (e.g. via Bluetooth) to an input of a control system housed in a control box on the wall outside the sports hall. An integrated security module in the control system holds a set of base keys, the same as the KIP that issued the encryption key to the user.

[0182] The app is configured to use the encryption key received from the KIP upon booking the time slot to construct a command data packet as described above and send the command data packet (with an unencrypted header and an encrypted command payload as described above) to an input of the control system. A security module of the control system verifies and decrypts the command data packet in the manner described above and, if successful, forwards the command data to a controller (MCU) that unlocks the doors of the sports hall. If the same control system does not control the lights, the user may need to repeat the process of turning the lights on using a different control system.

[0183] The door control system is capable of managing an unlimited number of reservations for different people at different times without the need for internet access as it does not require prior knowledge of the user or the times necessary for the user to access the system.

[0184] In another example, a method and apparatus for controlling the use of drones is envisioned. A company may store multiple drones in different locations for deployment at different times and in different regions. While the drones are stored, they should not be able to be launched or controlled, and it is essential to prevent unauthorized use even if the drone is lost or stolen. Furthermore, if different users need to access a single drone at different times, or if multiple users need to control the drone simultaneously but cannot share a key, the drone must be made user aware, which typically requires programming for each mission.

[0185] However, these problems can be avoided using methods and apparatus according to exemplary embodiments of the present invention. Each drone includes a control system that includes an integrated security module as generally described above. For example, a remote KIP can be notified that User X has access to Drone A within two days, and that User X has access to and control Drone A for 14 days. If User X requests access to the drone after two days, User X can request a valid encryption key from the KIP and use it to send valid command data packets to the drone's control system, thereby gaining control until the 14 days have passed. At that point, the KeyExpDate will have passed and the security module of the control system will no longer be able to successfully verify the command data packets. However, if the period needs to be extended, the KIP can be notified and User X can request a new valid encryption key and continue to send command data packets to the control system, thereby allowing continued operation without the need for programming.

[0186] As a result, access to each drone can be restricted to designated users for a specified date and / or period in the future. As explained above, it is also possible to extend a user's period of operation without reprogramming the drone. Since there are no fixed keys / passwords, drones that are in operation remain secure. If a drone is lost or stolen, the KIP can mark it as out of operation so that no further keys are issued.

[0187] From the above description, it will be apparent to those skilled in the art that modifications and variations can be made to the described embodiments without departing from the scope of the invention as defined by the appended claims.

Claims

1. 1. A computer-implemented method executed within a user controlled device for generating and transmitting a command data packet including command data configured to operate a control unit, the command data having a plurality of attributes associated therewith, the method comprising, under control of a processor of the user controlled device: - requesting a timed encryption key from a remote key issuing platform and receiving said timed encryption key from said key issuing platform, said timed encryption key being generated by said key issuing platform using a base key selected according to a particular one or more of said attributes associated with said command data; receiving from the key issuing platform, together with the timed encryption key, a checksum value representing at least a subset of the attributes of the command data, including the particular attribute or attributes used by the key issuing platform to select the base key; - encrypting at least said command data using said timed encryption key; - constructing a command data packet comprising a plain value header and an encrypted command payload, said plain value header comprising: data representing the subset of the attributes of the command data, excluding the particular attribute or attributes used by the key issuing platform to select the base key; said checksum value; constructing a command payload comprising at least the encrypted command data; - transmitting said command data packet to said control unit.

2. 2. The method of claim 1, further comprising receiving a key expiration date along with the timed encryption key from the key issuing platform and including data representative thereof in the plain value header of the command data packet.

3. A method according to claim 1 or claim 2, wherein requesting a time-limited encryption key comprises generating request data including data representative of the user-controlled device and the control unit to which a command data packet is required to be sent, and transmitting the request data to the remote key issuing platform.

4. Constructing a command data packet - constructing a plain value data package comprising said command data and a number of attributes associated therewith, generating a signature over said number of plain value attributes, and appending said signature to said plain value data package to generate a signed data package; - encrypting the signed data package using the timed encryption key to generate an encrypted command payload; - appending the encrypted command payload to the plain value header.

5. The method of claim 1 or claim 2, wherein the plain value header includes data representing a command time extracted from a real-time clock of the user control device and an owner ID representing a user of the user control device.

6. 1. A computer implemented method for receiving, validating and implementing valid command data received from a user controlled device, the method being executed on a control unit including a security module and a control processor, the security module having a plurality of base keys stored therein, the method comprising, under control of the processor of the security module: receiving a command data packet from a user control device, the command data packet including a plain value header and an encrypted command payload, the command payload including command data encrypted by at least a time-limited encryption key, the plain value header including: data representing the subset of the attributes of the command data, excluding the particular attribute or attributes used by a key issuing platform to select a base key from which the encryption key is generated; receiving, including the checksum value; - determining said one or more particular attributes using attribute data contained in said plain value header and said checksum value; - selecting a base key from said stored base keys associated with said particular attribute or attributes; - calculating the encryption key using the selected base key; - decrypting the command payload, including the command data, using the encryption key; - transferring the decoded command data to the control processor.

7. 7. The method of claim 6, comprising calculating the encryption key using the selected base key and the checksum value.

8. A method according to claim 6 or 7, wherein the plain value header includes data representing the expiry date and / or time of a key associated with the command data packet, the method further comprising checking the expiry date of the key against a date and / or time maintained in a real-time clock of the security module.

9. 8. A method according to claim 6 or 7, wherein one of the command data attributes is a command time, data representative thereof being included in the plain value header of the command data packet, the method further comprising comparing the command time with previously stored command times and / or a time held by a real time clock of the control unit to determine whether the command time is valid, and discarding the command data packet if it is not valid.

10. 1. A computer-implemented method executed on a key issuing platform for generating a time-limited encryption key for use by one or more remote user controlled devices for one or more control units, the method comprising, under control of a processor of the key issuing platform, - receiving a request for a timed encryption key from a remote user controlled device, the request including data representative of the user controlled device and a control unit to which the user controlled device wishes to issue a command; - determining one or more specific command data attributes and selecting, from a set of stored base keys, a base key that corresponds to said one or more specific command data attributes; - calculating a checksum value representing at least a subset of the command data attributes including the particular command data attribute or attributes used to select the base key; - calculating an encryption key using said selected base key; - transmitting the encryption key to the user controlled device together with the checksum value and data representing an expiration date of the key.

11. The method of claim 10 , wherein the encryption key is calculated using the base key and the checksum value.

12. 1. A computer implemented security module for integration onto a control unit chip, the security module having a processor and memory and a plurality of stored base keys, the security module executing instructions stored in the memory under control of the processor to: receiving a command data packet from a user control device, the command data packet including a plain value header and an encrypted command payload, the command payload including command data encrypted by at least a time-limited encryption key, the plain value header including: data representing the subset of the attributes of the command data, excluding the particular attribute or attributes used by a key issuing platform to select a base key from which the encryption key is generated; receiving, including the checksum value; - determining said one or more particular attributes using attribute data contained in said plain value header and said checksum value; - selecting a base key from said stored base keys associated with said particular attribute or attributes; - calculating the encryption key using the selected base key; - decrypting the command payload, including the command data, using the encryption key; - forwarding the decrypted command data to a control processor of the control unit.

13. A computer implemented control unit comprising an integrated circuit having a security module according to claim 12.

14. A method for executing a program comprising: a processor and a memory, the method comprising: executing instructions stored in the memory under the control of the processor; - requesting a timed encryption key from a remote key issuing platform and receiving said timed encryption key from said key issuing platform, said timed encryption key being generated by said key issuing platform using a base key selected according to a particular one or more of said attributes associated with said command data; receiving from the key issuing platform, together with the timed encryption key, a checksum value representing at least a subset of the attributes of the command data, including the particular attribute or attributes used by the key issuing platform to select the base key; - encrypting at least said command data using said timed encryption key; - constructing a command data packet comprising a plain value header and an encrypted command payload, said plain value header comprising: data representing the subset of the attributes of the command data, excluding the particular attribute or attributes used by the key issuing platform to select the base key; said checksum value; constructing a command payload comprising at least the encrypted command data; - transmitting said command data packet to a control unit.

15. A computer-implemented program comprising: a processor and a memory, and executing instructions in the memory under the control of the processor; - receiving a request for a timed encryption key from a remote user controlled device, the request including data representative of the user controlled device and a control unit to which the user controlled device wishes to issue a command; - determining one or more specific command data attributes and selecting, from a set of stored base keys, a base key that corresponds to said one or more specific command data attributes; - calculating a checksum value representing at least a subset of the command data attributes including the particular command data attribute or attributes used to select the base key; - calculating an encryption key using said selected base key; - transmitting the encryption key to the user controlled device together with the checksum value and data representing an expiration date of the key.

16. A computer program product comprising instructions for implementing a method according to claim 1, 2, 6, 7, 10 or 11.

17. A computer program comprising instructions for carrying out a method according to claim 1, 2, 6, 7, 10 or 11.

18. A non-transitory storage medium storing instructions that, when executed by a processor, cause the processor to perform a method according to claim 1, 2, 6, 7, 10 or 11.

19. 1. A communication system comprising a client device, a server and a key issuing platform, the server having an integrated security module, the security module and the client device communicatively connectable to the key issuing platform over a communications network, the client device communicatively connectable to the server over a designated communications link, the client device having an input for receiving an encryption key from the key issuing platform over the communications network, and an output for sending an encryption key request to the key issuing platform and an output for sending command data packets to the server; The key issuing platform executes instructions in a memory under control of a processor to: receiving a request for a timed encryption key from the client device, the request including data representative of the client device and a server to which the client device wishes to issue a command; - determining one or more specific command data attributes and selecting, from a set of stored base keys, a base key that corresponds to said one or more specific command data attributes; - calculating a checksum value representing at least a subset of the command data attributes including the particular command data attribute or attributes used to select the base key; - calculating an encryption key using said selected base key; - transmitting said encryption key to said client device together with said checksum value and data representative of the expiry date of said key, The client device executes instructions under control of a processor to receiving from the key issuing platform, together with the timed encryption key, a checksum value representing at least a subset of the attributes of the command data, including the particular attribute or attributes used by the key issuing platform to select the base key; - encrypting at least said command data using said timed encryption key; - constructing a command data packet comprising a plain value header and an encrypted command payload, said plain value header comprising: data representing the subset of the attributes of the command data, excluding the particular attribute or attributes used by the key issuing platform to select the base key; said checksum value; constructing a command payload comprising at least the encrypted command data; - transmitting said command data to said server; The server is configured to forward the received command data packets to the security module, which executes instructions in a memory under control of a processor to: receiving a command data packet from a client device, the command data packet including a plain value header and an encrypted command payload, the command payload including command data encrypted by at least a time-limited encryption key, the plain value header including: data representing the subset of the attributes of the command data, excluding the particular attribute or attributes used by a key issuing platform to select a base key from which the encryption key is generated; receiving, including the checksum value; - determining said one or more particular attributes using attribute data contained in said plain value header and said checksum value; - selecting a base key from said stored base keys associated with said particular attribute or attributes; - calculating the encryption key using the selected base key; - decrypting the command payload, including the command data, using the encryption key; - transferring said decoded command data to a control processor of said server.

Images