Patent Description:
Checking tire pressure is an important part of the maintenance of a vehicle. Tire pressures should be maintained at predetermined pressures to ensure that a tire performs as intended by the manufacturer.

<CIT> describes a method of copying data from a first device to a second device, each device comprising a wireless communication interface having a maximum range. The method comprises transmitting, by the first device, the data to a third device positioned within the maximum range of the first device, receiving and storing the data at the third device, moving the third device to a location within the maximum range of the second device, and transmitting by the third device, the data to the second device.

<CIT> describes a wireless tire monitoring system for a vehicle including at least one sensor unit for measuring at least one parameter relating to the condition of the tire. The sensor unit(s) may be paired with a mobile communication unit and an in-car unit to share encrypted data or other related information.

<CIT> describes a wireless cluster based system for communication between sensor networks. The system may include at least one cluster module having a repeater in communication with at least one sensor unit for measuring a parameter relating to a condition of an article. The article may be vehicle such as a trailer, truck or lorry and the parameter may relate to the condition of a tire of the vehicle.

<CIT> describes approaches for direct communications between tire pressure sensors. One sensor may act as a teacher while other sensors may act as students and learn from the teacher sensor.

A first aspect of the present invention provides a method of configuring a network of tire monitoring devices using an untrusted device, the method comprising: transmitting, by the untrusted device, first configuration data to a first tire monitoring device; receiving, by the untrusted device, a first input verifying that the first configuration data has been loaded to the first tire monitoring device and matches expected first configuration data; transmitting, by the untrusted device, second configuration data to a second tire monitoring device; receiving, by the untrusted device, a second input verifying that the second configuration data has been loaded to the second tire monitoring device and matches expected second configuration data; and after receipt of both the first input and the second input, transmitting, by the untrusted device, a command initialising generation of a cryptographic parameter by the first tire monitoring device, and causing the cryptographic parameter to be exchanged with the second tire monitoring device such that secure future communication is established between the first and second tire monitoring devices.

The method according to the first aspect of the present invention may be advantageous as it may enable the first and second tire monitoring devices to be loaded with respective configuration data and verified sequentially prior to initialisation of generation of the cryptographic parameter by the first tire monitoring device. This may facilitate configuration of the network of tire monitoring devices as it may ensure that the first and second configuration data is properly loaded in the first and second tire monitoring devices prior to the cryptographic parameter being generated. For example, this may find particular utility where the cryptographic parameter is based, at least in part, on any of the first and second configuration data. Furthermore, the method allows the first and second tire monitoring devices to establish secure communication between themselves without the untrusted device subsequently knowing the parameters of the secure communication, so the untrusted device cannot later eavesdrop or pose a risk to the secure communication.

The method according to the first aspect of the present invention may further facilitate configuration of the network of tire monitoring devices, as the sequential loading and verification of configuration data at the first and second tire monitoring devices may provide a relatively simple and efficient method for an operator performing the method utilising the untrusted device. For example, as the first configuration data is transmitted and subsequently verified prior to the second configuration data being transmitted and subsequently verified, the operator may be able to perform steps required for configuring the first tire monitoring device prior to performing steps required for configuring the second tire monitoring device. This may, for example, find particular utility where the tire monitoring devices are installed on respective tires of an aircraft, for example enabling a single circuit of the aircraft to be performed by an operator in order for the configuration of the network of tire monitoring devices to take place.

In general, a cryptographic parameter, may be anything used for cryptography, including but not limited to cryptographic commitments and keys (symmetrical and asymmetric). In an example, the cryptographic parameter comprises a cryptographic commitment generated by the respective tire monitoring device.

The network of tire monitoring devices may comprise a wireless network of tire monitoring devices.

Optionally, the method comprises, when the first input is not received, and prior to transmitting, by the untrusted device, the second configuration data to the second tire monitoring device, re-attempting verification of the first configuration data, and indicating a fault condition if the first input continues not to be received.

This may facilitate configuration of the network of tire monitoring devices by an operator utilising the untrusted device, as the operator may be able to ensure that the first configuration data has been loaded correctly prior to attempting to load the second configuration data. This may, for example, find particular utility where the tire monitoring devices are installed on respective tires of an aircraft, for example enabling a single circuit of the aircraft to be performed by an operator in order for the configuration of the network of tire monitoring devices to take place.

Optionally, the method comprises, when the first input continues not to be received after re-attempting verification of the first configuration data, re-transmitting, by the untrusted device, the first configuration data to the first tire monitoring device, re-attempting verification of the first configuration data after the re-transmitting, and indicating a further fault condition if the first input still continues not to be received.

Optionally, the first and/or second configuration data comprises any of an aircraft wheel location at which the tire monitoring device is intended to be located, and a reference pressure for a tire of a wheel to which the tire monitoring device corresponds.

Optionally, verifying that the first configuration data loaded to the first tire monitoring device matches expected first configuration data comprises transmitting, by the first tire monitoring device, a configuration data signal which encodes the first configuration data, wherein the configuration data signal is configured to be received and understood by a human, and receiving, by the untrusted device, the first input via a human interaction with the untrusted device. Optionally, the configuration data signal is transmitted in response to a transmission request sent by the untrusted device.

Optionally, the configuration data signal comprises a visual signal, and the visual signal is transmitted using a visual indicator of the first tire monitoring device.

Optionally, the visual indicator comprises a light source, and the method comprises selectively illuminating the light source to transmit the configuration data signal.

Optionally, the configuration data signal comprises a number, and the selective illumination of the light source comprises encoding the number into an illumination sequence representing individual digits of the number.

Optionally, verifying that the second configuration data loaded to the second tire monitoring device matches expected second configuration data comprises transmitting, by the second tire monitoring device, a further configuration data signal which encodes the second configuration data, wherein the further configuration data signal is configured to be received and understood by a human, and receiving, by the untrusted device, the second input via a human interaction with the untrusted device. Optionally, the further configuration data signal is transmitted in response to a further transmission request sent by the untrusted device.

Optionally, the further configuration data signal comprises a visual signal, and the visual signal is transmitted using a visual indicator of the second tire monitoring device.

Optionally, the visual indicator comprises a light source, and the method comprises selectively illuminating the light source to transmit the further configuration data signal.

Optionally, the further configuration data signal comprises a number, and the selective illumination of the light source comprises encoding the number into an illumination sequence representing individual digits of the number.

Optionally, the method comprises receiving, at the untrusted device, the first configuration data prior to transmitting the first configuration data to the first tire monitoring device. For example, an operator of the untrusted device, who may comprise a trusted source, may input the first configuration data into the untrusted device prior to transmitting the first configuration data to the first tire monitoring device.

Optionally, the method comprises transmitting, via the untrusted device, a further command waking the first tire monitoring device prior to transmission of the first configuration data to the first tire monitoring device.

Optionally, the command is transmitted using a relatively long-range communication protocol, and the further command is transmitted using a relatively short-range communication protocol. This may be beneficial as the command may be transmitted to the first tire monitoring device from a location remote from the first tire monitoring device, whilst the further command may be transmitted from a region in close proximity to the device. This may enable the operator of the untrusted device to initiate the method of configuring the network of tire monitoring devices at the first tire monitoring device, whilst finishing the method of configuring the network of tire monitoring devices at a location remote from the first tire monitoring device. This may, for example, find particular utility where the tire monitoring devices are installed on respective tires of an aircraft, for example enabling a single circuit of the aircraft to be performed by an operator in order for the configuration of the network of tire monitoring devices to take place.

The command may be transmitted via a communication protocol having a maximum transmission range of <NUM>, <NUM>, <NUM>, or less, whilst the further command may be transmitted via a communication protocol having a maximum transmission range of <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or less. The command may be transmitted via Bluetooth® and/or the further command may be transmitted via any of near-field communication (NFC). The further command may be transmitted in response to scanning, using the untrusted device, of a QR code or barcode on the first tire monitoring device.

Optionally, the command comprises a plurality of commands. For example, the command may comprise a first command initialising generation of a cryptographic parameter by the first tire monitoring device, and a second causing the cryptographic parameter to be exchanged with the second tire monitoring device.

Optionally the command initialises generation of a cryptographic parameter by the first tire monitoring device and a further cryptographic parameter by the second tire monitoring device, and causes the cryptographic parameter and the further cryptographic parameter to be exchanged between the first and second tire monitoring devices such that secure future communication is established between the first and second tire monitoring devices. Optionally, the command is broadcast from the untrusted device to each of the first and second tire monitoring devices. Optionally, the command is unicast from the untrusted device to the respective first and second tire monitoring devices.

Optionally, the method comprises transmitting, via the untrusted device, a second further command waking the second tire monitoring device prior to transmission of the second configuration data to the second tire monitoring device.

Optionally, the second further command is transmitted using the relatively short-range communication protocol.

Optionally, the method comprises initiating, via the untrusted device, a tire check once secure future communication is established between the first and second tire monitoring devices. Optionally, the tire check may be initiated via transmission of a tire check request from the untrusted device to the first tire monitoring device, for example using the relatively long-range communication protocol.

Optionally, the method comprises transmitting, by the untrusted device, third configuration data to a third tire monitoring device, receiving, by the untrusted device, a third input verifying that the third configuration data has been loaded to the third tire monitoring device and matches expected third configuration data, and after receipt of the first, second and third inputs, transmitting, by the untrusted device, the command initialising generation of the cryptographic parameter by the first tire monitoring device, and causing the cryptographic parameter to be exchanged with the second and third tire monitoring devices such that secure future communication is established between the first, second and third tire monitoring devices.

Optionally the tire monitoring devices comprise tire pressure monitoring devices.

Optionally, the method comprises, where verifying that the first configuration data loaded to the first tire monitoring device matches expected first configuration data fails, and/or where verifying that the second configuration data loaded to the second tire monitoring device matches expected second configuration data fails, any of: re-attempting verification of the respective first and/or second configuration data; re-transmitting the first and/or second configuration data to the respective first and second tire monitoring device; and indicating a fault condition.

Also described herein is a method of configuring a network of tire pressure monitoring devices using an untrusted device, the method comprising: transmitting, by the untrusted device, respective configuration data to the tire pressure monitoring devices; receiving, by the untrusted device, respective inputs verifying that the installed configuration data matches expected configuration data; and after receiving the respective inputs, transmitting, by the untrusted device, a command initialising generation of a cryptographic parameter by at least one of the tire pressure monitoring devices, and causing the cryptographic parameter to be exchanged with the other tire pressure monitoring devices such that secure future communication is established between the tire pressure monitoring devices, wherein the tire pressure monitoring devices are installed with the respective configuration data, and respective inputs verifying that the installed configuration data matches expected configuration data are received by the untrusted device, sequentially prior to transmission of the command, with configuration data transmitted to a tire pressure monitoring device and verified via the respective input prior to transmission of configuration data to a next sequential tire pressure monitoring device.

According to a second aspect of the present invention there is provided a tire monitoring network comprising first and second tire monitoring devices configured by a method according to the first aspect of the present invention.

According to a third aspect of the present invention there is provided an aircraft comprising the tire monitoring network according to the second aspect of the present invention.

A tire pressure monitoring device <NUM> according to an example is shown schematically in <FIG>. The tire pressure monitoring device <NUM> comprises a processor <NUM>, a memory <NUM>, a transceiver <NUM>, a visual indicator or display which is an LED <NUM> in this example, a sensor <NUM> and a power source <NUM>.

The processor <NUM> may be any suitable processor including single and multi-core processors, an Application Specific Integrated Circuit (ASIC) or like. The processor <NUM> is communicatively coupled to the transceiver <NUM>, the LED <NUM>, the memory <NUM> and the power source <NUM>. The processor <NUM> is configured to generate various cryptographic parameters, as will be discussed hereinafter.

Memory <NUM> is a flash memory that stores configuration data <NUM> and also computer readable instructions for execution by the processor <NUM> in operation, although it will be appreciated that other types of memory may be used. The configuration data <NUM> can therefore be updated as required with configuration data. A reference tire pressure is stored in the configuration data <NUM>. Additional data can also be stored in the configuration data <NUM>, for example an aircraft identifier (such as an aircraft Tail identifier) and a wheel position.

Transceiver <NUM> is an appropriate transceiver capable of receiving a request to confirm the configuration data <NUM>. In this example, the transceiver <NUM> comprises a first <NUM> short-range radio signal transceiver operating according to the NFC protocol, and a second <NUM> transceiver operating according to a Bluetooth low energy (BLE) communication protocol. Although described here as operating according to specific protocols, it will be appreciated that other embodiments where the first <NUM> and second <NUM> transceivers operate according to different protocols, for example with the second transceiver <NUM> operating via a WiFi protocol, are also envisaged. When the transceiver <NUM> receives a request to confirm the configuration data <NUM>, the processor <NUM> encodes the configuration data <NUM> stored in the memory <NUM> of the tire pressure monitoring device <NUM>, and transmits a signal <NUM> indicative of the configuration data <NUM> via the LED <NUM> to a user <NUM> observing the tire pressure monitoring device <NUM>. Here the LED <NUM> is a three-colour LED which is capable of displaying red, blue, and green coloured light. Other examples may use a different number of colours of light than three and/or use other colours than red, blue, and green. Still further examples may utilise a display screen, for example an LCD screen, instead of or in addition to the LED <NUM>. In examples herein, the user <NUM> is a human. As the user <NUM> can be taken to be a trusted source, and the tire pressure monitoring device <NUM> is itself a trusted source, an untrusted device <NUM> can be used to input the user's verification of the configuration data <NUM>, as will be discussed in more detail hereafter.

The transceiver <NUM> is further able to transmit and receive cryptographic parameters from the tire monitoring device <NUM> to other tire monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>, as will be discussed in more detail hereafter.

The tire pressure monitoring device <NUM> is installed on an aircraft <NUM> in use, and is one of a network <NUM> of tire pressure monitoring devices, with the aircraft <NUM> illustrated schematically in <FIG>, and the network <NUM> of tire pressure monitoring devices illustrated schematically in <FIG>. As an example, the aircraft <NUM> has a first group <NUM> of two nose wheels, and a second group <NUM> of four main landing gear wheels. Each wheel in the first <NUM> and second <NUM> groups of wheels has an associated tire pressure monitoring device, such that there are six tire pressure monitoring devices installed on the aircraft <NUM>.

As illustrated in <FIG>, the tire pressure monitoring device <NUM> is a first tire pressure monitoring device utilised as left nose tire pressure monitoring device <NUM>, with a second tire pressure monitoring device <NUM> being a right nose tire pressure monitoring device, a third tire pressure monitoring device <NUM> being a first main landing gear tire pressure monitoring device, a fourth tire pressure monitoring device <NUM> being a second main landing gear tire pressure monitoring device, a fifth tire pressure monitoring device <NUM> being a third main landing gear tire pressure monitoring device, and a sixth tire pressure monitoring device <NUM> being a fourth main landing gear tire pressure monitoring device. It will be appreciated that each of the second <NUM> through sixth <NUM> tire pressure monitoring devices has substantially the same structure and functionality as the first tire pressure monitoring device <NUM> illustrated in <FIG>. It will further be appreciated that the locations of each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> are illustrative only, and that any of the tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> could be used at any wheel location on an aircraft, if so desired.

When initially installed on the aircraft <NUM>, the tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> are not configured, ie do not store the configuration data <NUM>, and are incapable of direct communication between one another. The user <NUM> therefore uses the untrusted device <NUM> to configure the network <NUM> of tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, as will now be described.

Initially, the user <NUM> approaches the first tire pressure monitoring device <NUM> to begin configuration. The user <NUM> inputs the desired configuration data <NUM> for the first tire pressure monitoring device <NUM>, including the wheel location and reference pressure, into the untrusted device <NUM>, and the first tire pressure monitoring device <NUM> is touched with the untrusted device <NUM> to establish near field communication using the first transceiver <NUM>. The desired configuration data <NUM> may also include an aircraft tail ID, or any other appropriate configuration parameter. The near field communication is used to uniquely identify the tire pressure monitoring device <NUM> to the untrusted device <NUM>. The configuration data <NUM> is then transferred from the untrusted device <NUM> to the first tire pressure monitoring device <NUM> via a Bluetooth ® low energy protocol using the second transceiver <NUM> as previously described. The configuration data <NUM> is then stored in the memory <NUM>, with the first tire pressure monitoring device <NUM> deleting any previously stored configuration data before the newly received configuration data <NUM> is stored. In other examples the configuration data <NUM> is transferred from the untrusted device <NUM> to the first tire pressure monitoring device <NUM> via near field communication.

Once the configuration data <NUM> has been stored, the processor <NUM> generates a key pair comprising a public key <NUM> and a private key <NUM>, along with a random number <NUM>, with use of these parameters described in more detail herein.

Whilst still at the first tire pressure monitoring device <NUM> the user <NUM> checks that the configuration data <NUM> that has been stored correctly in the memory <NUM>, with the task being led by an aircraft maintenance manual (AMM).

One piece of configuration data <NUM> to be checked is the installed location of the first tire pressure monitoring device <NUM>. Here, as an example, an AMM task card may provide to the user a list of tire pressure monitoring device locations, eg nose left, nose right, and so on, along with an associated expected flash sequence for the LED <NUM> which would correctly indicate the associated tire pressure monitoring device location. In the case of the first tire pressure monitoring device <NUM>, which is used as the left nose tire pressure monitoring device in the example previously described, an appropriate flash sequence of the LED <NUM> may be one green flash, followed by five blue flashes, followed by one red flash. Illustrative appropriate flash sequences (ie signals <NUM>) for tire pressure monitoring device location are shown schematically in <FIG>.

When checking the stored location of the first tire pressure monitoring device <NUM>, the user <NUM> submits a request for the first tire pressure monitoring device <NUM> to display the stored location, via the LED <NUM>, using a user interface of the untrusted device <NUM>. The untrusted device <NUM> does not tell the first tire pressure monitoring device <NUM> which sequence to flash, but rather provides an instruction for the first tire pressure monitoring device <NUM> to flash its sequence indicative of the stored location. An exemplary user interface <NUM> for starting the check is shown in <FIG>, with the user interacting with user interface element <NUM> to start the check. An exemplary user interface <NUM> for a user <NUM> to verify the signal <NUM> is shown in <FIG>, with the user <NUM> interacting with user interface elements <NUM>,<NUM> to indicate whether the signal <NUM> is verified or not. If the signal <NUM>, here indicative of stored location of the first tire pressure monitoring device <NUM>, is not verified, then the configuration data <NUM> needs to be reloaded, with the process described above repeated. In other examples, if the signal <NUM>, here indicative of stored location of the first tire pressure monitoring device <NUM>, is not verified, the request and subsequent flash sequence is repeated, or the first tire pressure monitoring device <NUM>, the untrusted device <NUM>, or an application running on the untrusted device <NUM>, is replaced.

As the user <NUM> can be taken to be a trusted source, and the first tire pressure monitoring device <NUM> is itself a trusted source, the untrusted device <NUM> can be used to input the user's verification of the configuration data <NUM>. The verification can be trusted because it occurs between the user <NUM> (who is trusted) and tire pressure monitoring device <NUM> (which is trusted because of its certification to a particular DAL).

Another piece of configuration data <NUM> to be checked is the stored reference pressure of the first tire pressure monitoring device <NUM>. Here, as an example, an AMM task card may provide to the user <NUM> a list of reference pressures for different tire pressure monitoring device locations, eg nose left, nose right, and so on, along with an associated expected flash sequence for the LED <NUM> which would correctly indicate the associated tire pressure monitoring device reference pressure. In the case of the first tire pressure monitoring device <NUM>, which is used as the left nose tire pressure monitoring device in the example previously described, an appropriate reference pressure may be <NUM> PSI (<NUM>,<NUM> kPa). Here separate flash sequences of the LED <NUM> may be performed for each digit of the reference pressure, ie a first flash sequence/signal <NUM> for the "hundreds" digit, a second flash sequence/signal <NUM> for the "tens" digit, and a third flash sequence/signal <NUM> for the "units" digit. The first flash sequence of the LED <NUM> in such a case may be one green flash, followed by one blue flash, followed by one red flash. The second flash sequence of the LED <NUM> in such a case may be one green flash, followed by seven blue flashes, followed by one red flash. The third flash sequence of the LED <NUM> in such a case may be one green flash, followed by eight blue flashes, followed by one red flash. Illustrative appropriate flash sequences (ie signals <NUM>) for tire pressure monitoring device reference pressure are shown schematically in <FIG>.

When checking the stored reference pressure of the first tire pressure monitoring device <NUM>, the user <NUM> submits a request for the first tire pressure monitoring device <NUM> to display the stored reference, via the LED <NUM>, using a user interface of the untrusted device <NUM>. The untrusted device <NUM> does not tell the first tire pressure monitoring device <NUM> which sequence to flash, but rather provides an instruction for the first tire pressure monitoring device <NUM> to flash its sequence indicative of the stored reference pressure. An exemplary user interface <NUM> for starting the check for the "hundreds" digit is shown in <FIG>, with the user <NUM> interacting with user interface element <NUM> to start the check for the "hundreds" digit. An exemplary user interface <NUM> for a user <NUM> to verify the signal <NUM> for the "hundreds" digit is shown in <FIG>, with the user <NUM> interacting with user interface elements <NUM>,<NUM> to indicate whether the signal <NUM> is verified or not.

Similarly an exemplary user interface <NUM> for starting the check for the "tens" digit is shown in <FIG>, with the user <NUM> interacting with user interface element <NUM> to start the check for the "tens" digit. An exemplary user interface <NUM> for a user <NUM> to verify the signal <NUM> for the "tens" digit is shown in <FIG>, with the user <NUM> interacting with user interface elements <NUM>,<NUM> to indicate whether the signal <NUM> is verified or not. An exemplary user interface <NUM> for starting the check for the "units" digit is shown in <FIG>, with the user <NUM> interacting with user interface element <NUM> to start the check for the "units" digit. An exemplary user interface <NUM> for a user to verify the signal <NUM> for the "units" digit is shown in <FIG>, with the user <NUM> interacting with user interface elements <NUM>,<NUM> to indicate whether the signal <NUM> is verified or not.

Once the desired configuration data <NUM> has been verified for the first tire pressure monitoring device <NUM>, the user can move to the next tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM> and perform the same steps to ensure configuration of each of the tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>.

As will be appreciated from the discussion above, during the process of configuring each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, each tire monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> generates a respective key pair comprising a public key 212a-212f and a private key 214a-214f, along with a random number 216a-216f. This is illustrated schematically in <FIG>, and these cryptographic parameters are utilised to establish secure communication within the network <NUM> of tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>. The key pair and random number can be generated in any suitable way, in this example, the key pair is generated using any suitable cryptographic pseudo-random generator.

As a first step in establishing secure communication, illustrated schematically in <FIG>, each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, responsive to a command from the untrusted device <NUM>, broadcasts, in a respective first message 218a-218f, its public key 212a-212f and its configuration data <NUM> to each of the other tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>. In other words, each tire pressure monitoring device broadcasts the first message to all of the other tire pressure monitoring devices. The untrusted device <NUM> is used as a router for the first messages 218a-218f, with each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> receiving the other first messages 218a-218f via the untrusted device. Here bold arrows denote sent messages, whilst non-bold arrows denote received messages. The first messages 218a-218f are broadcast and received via the second receiver <NUM> of each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, using a BLE protocol. Once all first messages 218a-218f are sent and received, each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> knows the public key 212a-212f and configuration data <NUM> of each other tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>. By broadcasting the first messages 218a-218f from the tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, a number of messages sent by each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> may be reduced compared to, for example, an arrangement where each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> unicasts its public key 212a-212f and/or its configuration data <NUM> to each other tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>. Through the use of a broadcast message, a single transmitted message from a tire monitoring device may be received by a plurality of other devices, reducing message traffic and saving power. As illustrated in <FIG>, a single transmitted message is received by all of the other tire monitoring devices.

As a second step in establishing secure communication, illustrated schematically in <FIG>, the processor <NUM> of each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> uses its own random number <NUM>-216f, the public keys 212a-212f both generated and received by the tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, and its own configuration data <NUM>, to generate a cryptographic commitment 220a-220f. The cryptographic commitment can be generated in any suitable way, in this example it is generated using a hash-based concurrent non-malleable commitment. Each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> broadcasts, in a second message 222a-222f, its respective cryptographic commitment 220a-220f to each of the other tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>.

The untrusted device <NUM> is used as a router for the second messages 222a-222f, with each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> receiving the other second messages 222a-222f via the untrusted device <NUM>. Here bold arrows denote sent messages, whilst non-bold arrows denote received messages. The second messages 222a-222f are broadcast and received via the second receiver <NUM> of each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, using a BLE protocol. Once all second messages 222a-222f are sent and received, each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> knows the cryptographic commitment 220a-220f of each other tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>. By broadcasting the second messages 222a-222f from the tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, a number of messages sent by each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> may be reduced compared to, for example, an arrangement where each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> unicasts its cryptographic commitment 220a-220f to each other tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>.

As a third step in establishing secure communication, illustrated schematically in <FIG>, each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> broadcasts, in a respective third message 224a-224f, an input 226a-226f to open the respective cryptographic commitment 220a-220f, to each other tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>. Here bold arrows denote sent messages, whilst non-bold arrows denote received messages. The third messages 224a-224f are broadcast and received via the second receiver <NUM> of each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, using a BLE protocol. Once all third messages 224a-224f are sent and received, each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> can open and verify the cryptographic commitments 220a-220f received from the other tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>. By broadcasting the third messages 224a-224f from the tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, a number of messages sent by each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> may be reduced compared to, for example, an arrangement where each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> unicasts its input 226a-226f to each other tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>.

Where a cryptographic commitment 220a-220f cannot be verified, the establishment of secure communication is aborted, and an error message is communicated to the untrusted device <NUM>. For example, the error message could be communicated using Bluetooth ® or NFC to the untrusted device <NUM> for display by the untrusted device <NUM>. Alternatively, or additionally, the error message could be communicated using the LED of the tire pressure monitoring device, such as by lighting the LED continuously red.

Where the cryptographic commitments 220a-220f are all verified, each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> generates, for each other tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, a seed for a pseudo-random generator. The generation of the seed comprises utilising a hash function with inputs of the private key 214a-214f of the tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> performing the generation, and the public key 212a-212f of the tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> for which generation is being performed.

Using the pseudo random generator, each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> generates a shared key pair comprising a first shared key k, and a second shared key k', using any suitable cryptographic pseudo-random generator such as AES in counter mode.

Each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> then generates, for each other tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, a value using a pseudo-random function based on the first shared key k, and associated random numbers 216a-216f and the respective public keys 212a-212f of the two tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> in question as inputs to the pseudo-random function. The pseudo-random function may comprise any suitable cryptographic pseudo-random function such as HMAC.

Each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> sends its respective values to the other tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, with each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> checking validity of the received values using the same pseudo-random function based on the first shared key k.

Where a value cannot be verified, the establishment of secure communication is aborted, and an error message is communicated to the untrusted device <NUM>. For example the error message could be communicated using Bluetooth ® or NFC to the untrusted device <NUM> for display by the untrusted device <NUM>. Alternatively, or additionally, the error message could be communicated using the LED of the tire pressure monitoring device, such as by lighting the LED continuously red.

Where values are verified, the respective tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> use the respective second shared keys k' for secure future communication. Although the establishment of the secure communication required the use of unencrypted messages between the tire pressure monitoring devices, the untrusted device <NUM> cannot know the second shared keys k' because generating these requires knowledge of the private keys that are not shared.

In such a manner secure communication can be established between tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> of the network <NUM>, i.e. with secure communication established on a pair-wise basis. The untrusted device does not know the second shared keys k' used for communication, and the numbers of messages required to be exchanged is reduced by the use of broadcast messages. Furthermore, the secure communication does not require a pre-installed key or the like on the tire pressure monitoring devices <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>.

Where secure communication has been established, the tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> can be used to communicate to the user that each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> shares the same security code. Here each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> generates a numerical value, representing a security code, that can be communicated to the user <NUM> by flashing the LED <NUM> in a manner similar to that previously described in relation to the checks of configuration data <NUM>. The numerical value in some examples comprises a truncated hash of the configuration data <NUM>, public keys 212a-212f and random numbers 216a-216f, such as a truncated hash function with an input of a concatenation of the configuration data <NUM>, public keys 212a-212f and random numbers 216a-216f. Any suitable hash function can be used, such as SHA-<NUM>. As each of the tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> knows the same configuration data <NUM>, public keys 212a-212f and random numbers 216a-216f, the truncated hash, and hence the security code, should be the same for each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>.

Checking of security codes is, in some examples, led by the aircraft maintenance manual (AMM), with an AMM task card being utilised by the user <NUM> to fill in security codes indicated by the received signals <NUM>. Similar to the signals for reference pressure discussed in relation to <FIG> and <FIG>, signals <NUM> indicative of security codes communicated by flashing the LEDs <NUM> of the tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> may comprise three digits, with each digit, ie "hundreds", "tens", "units" flashed using a separate signal <NUM>. Each separate signal <NUM> may comprise a green flash to start, a red flash to end, and a number of blue flashes intermediate the green and red flashes to indicate the digit to the user <NUM>. The AMM may provide the option for a user to indicate whether an observed flash is short (i.e. quick) or long (i.e. slow). User interfaces on the untrusted device <NUM> may be used to initiate transmission of a signal <NUM>, and to confirm once a signal <NUM> has been received by the user <NUM>.

Where the security codes flashed by the LEDs <NUM> of each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> match, successful configuration may be determined. Where any of the security codes do not match, this is considered indicative of incorrect configuration, and re-configuration of the network <NUM> of tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> needs to take place.

Pseudo code illustrating the steps involved in establishing secure communication and checking security codes is illustrated in <FIG>. Here PSD refers to a tire pressure sensing device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, UDEV refers to the untrusted device <NUM>, pk denotes the public keys 212a-212f, sk denotes the private keys 214a-214f, r denotes the random numbers 216a-216f, and config denotes the relevant configuration data <NUM>.

As mentioned above, in some examples broadcasting messages from a tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> to the other tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> may reduce message count compared to a similar arrangement where each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> unicasts a message to each other tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>. Such methods may, in some examples, be thought of as comprising broadcasting, from each tire monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> to each other tire monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, a message comprising a cryptographic parameter generated by that respective tire monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>.

A method <NUM> illustrating steps involved in establishing secure communication in a network of tire pressure monitoring devices, in accordance with the previously described examples, is illustrated in the flow diagram of <FIG>.

The method <NUM> comprises generating <NUM>, at each tire monitoring device, a public key, and broadcasting <NUM>, from each tire monitoring device to each other tire monitoring device, the respective public keys. The method <NUM> comprises generating <NUM>, at each tire monitoring device, a cryptographic commitment using the public keys generated and received by the respective tire monitoring device, and broadcasting <NUM>, from each tire monitoring device to each other tire monitoring device, the respective cryptographic commitments. The method <NUM> comprises broadcasting <NUM>, from each tire monitoring device to each other tire monitoring device, an input to open the cryptographic commitment generated by that tire monitoring device, and verifying <NUM>, at each tire monitoring device, the commitments received by the respective tire monitoring device using the respective inputs.

The method <NUM> comprises generating <NUM>, at each tire monitoring device, a shared key pair for the tire monitoring device and each other tire monitoring device, each shared key pair comprising a first shared key and a second shared key, and generating <NUM>, at each tire monitoring device, using a function based on the respective first shared keys, a value to communicate to each other tire monitoring device. The method <NUM> comprises unicasting <NUM>, from each tire monitoring device to each other tire monitoring device, a respective generated value to each other tire monitoring device, and verifying <NUM>, at each tire monitoring device, received generated values. Where received generated values are correctly verified, the method <NUM> comprises establishing <NUM> secure future communication between respective tire monitoring devices using the respective second shared keys. In some examples, the method <NUM> may then comprise a step of performing a tire pressure check using the generated cryptographic keys, such that data transferred between the tire monitoring devices is secured.

By utilising the method <NUM>, secure communication between tire pressure monitoring devices can be established, whilst reducing message count via use of broadcasting rather than unicasting. For example, if a protocol similar to Bluetooth's numeric comparison mode were used to establish pairwise keys between the tire monitoring devices, then to establish keys between n tire monitoring devices would require n * (n-<NUM>)/<NUM> executions of the Bluetooth numeric comparison protocol. This would imply that each of the n tire monitoring devices sends (in the order of) n messages, and the user would have to verify each of the n*(n-<NUM>)/<NUM> keys manually. In contrast, with the method <NUM>, each tire monitoring device only sends (in the order of) one single message. The method <NUM> also enables a high level of security to be maintained in setting-up the secure communication.

It will be appreciated that the use of broadcast messages can be applied to methods to establish secure communication between devices other than the specific examples described herein. For example, when a plurality of devices are all establishing secure communication at the same time, broadcast messages may be useful to reduce message traffic when a plurality of devices all need to receive the same piece of information (such as a device's public key). Alternatively, or additionally, broadcast messages can reduce message traffic by combining messages for multiple recipients into a single message, with each recipient retrieving its part of the combined message.

From the discussion above, it will further be appreciated that, when configuring the network <NUM> of tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> is loaded with configuration data <NUM> and verified before moving on to the next tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>. In such a manner the tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> are loaded and verified sequentially. Furthermore, once the tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> have all been loaded and verified, the process of establishing secure future communication can be initialised by the user <NUM> using the untrusted device <NUM>.

In particular, the user <NUM> can initialise the process of establishing secure further communication by using the untrusted device <NUM> to send a command to the tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> to broadcast, in a respective first message 218a-218f, their public key 212a-212f and their configuration data <NUM> to each of the other tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, as outlined with respect to <FIG> above. Such a command is sent via Bluetooth®, with the user <NUM> stood at an appropriate location within range of each of the tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>. The subsequent steps of <FIG>, can then take place, either automatically or in response to further commands issued via the untrusted device <NUM>.

In such a manner, configuration of the network <NUM> of tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> can take place in an efficient manner by the user <NUM>. In particular, the user <NUM> need only make a single circuit of the tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> in order to load and subsequently verify the configuration data <NUM> of the tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, before initialising establishment of secure future communication in the manner previously described.

A method <NUM> associated with configuring the network <NUM> of tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> is illustrated in <FIG>.

The method <NUM> comprises transmitting <NUM>, by the untrusted device <NUM>, first configuration data to a first tire monitoring device, and receiving <NUM>, by the untrusted device <NUM>, a first input verifying that the first configuration data has been loaded to the first tire monitoring device and matches expected first configuration data.

The method <NUM> comprises transmitting <NUM>, by the untrusted device <NUM>, second configuration data to a second tire monitoring device, and receiving <NUM>, by the untrusted device, a second input verifying that the second configuration data has been loaded to the second tire monitoring device and matches expected second configuration data. The method <NUM> comprises, after receipt of both the first input and the second input, transmitting <NUM>, by the untrusted device, a command initialising generation of a cryptographic parameter by the first tire monitoring device, and causing the cryptographic parameter to be exchanged with the second tire monitoring device such that secure future communication is established between the first and second tire monitoring devices.

It will be appreciated that further steps of transmitting configuration data and receiving inputs verifying configuration data can take place, prior to transmission <NUM> of the command initialising generation of the cryptographic parameter by the first tire monitoring device, depending on the number of tire pressure monitoring devices to be configured.

Where configuration data <NUM> cannot be verified by the user <NUM>, such as where the sequence flashed by the LED <NUM> does not match an expected sequence, steps may be taken to ensure that configuration data <NUM> has been correctly loaded. One such example method <NUM> is depicted in <FIG>. At <NUM> it is determined whether input has been received that the configuration is verified. For example, no input verifying that the displayed sequence matches the expected sequence may have been received (such as after a timer expires without input) or an input indicating that the sequence did not match that expected has been received. If an input was received, the method continues to block <NUM>, and the method of <FIG> continues. If no input verifying configuration is received, the relevant tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> may be caused or commanded to re-display the stored configuration data <NUM>, via the LED <NUM> at block <NUM>. This can check for possible human error in identifying the expected sequence.

At block <NUM>, if no input is received that the re-displayed configuration data <NUM> matches the expected configuration data, such as receiving a further input that the LED flashes did not match the expected sequence or a further timeout elapsing, that particular tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, can be reloaded with the configuration data <NUM> at block <NUM> and a subsequent verification attempt made. This can check for a possible error when loading the data. If no input that the stored configuration data <NUM> matches the expected configuration data is again received at block <NUM>, the untrusted device <NUM> can indicate a fault condition at block <NUM>, with the fault condition indicative of a fault with the tire pressure monitoring device in question and/or a fault with the untrusted device <NUM>. Configuration of the tire monitoring devices may then end, until the fault is resolved by replacing the tire pressure monitoring device and/or the untrusted device <NUM>.

In any of blocks <NUM>, <NUM> and <NUM> receipt of input that the configuration is verified causes the configuration process of <FIG> to resume, such as with the configuration of a subsequent tire pressure monitoring device, or by transmitting the command initialising generation of the cryptographic parameter if all the tire monitoring devices are configured.

By taking the above steps, incorrect loading of configuration data <NUM> can be identified whilst the user <NUM> is at a particular tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM>, which may prove more efficient than, for example, a method where verification steps are not performed until each tire pressure monitoring device <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> has been loaded. In particular, the steps described above may facilitate the user <NUM> needing only to make a single circuit of the tire pressure monitoring devices <NUM>,<NUM>,<NUM>,<NUM>,<NUM>,<NUM> in order to load and subsequently verify the configuration data <NUM>.

Claim 1:
A method (<NUM>) of configuring a network (<NUM>) of tire monitoring devices (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) using an untrusted device (<NUM>), the method comprising:
transmitting (<NUM>), by the untrusted device (<NUM>), first configuration data to a first tire monitoring device;
receiving (<NUM>), by the untrusted device (<NUM>), a first input verifying that the first configuration data has been loaded to the first tire monitoring device and matches expected first configuration data;
transmitting (<NUM>), by the untrusted device (<NUM>), second configuration data to a second tire monitoring device;
receiving (<NUM>), by the untrusted device (<NUM>), a second input verifying that the second configuration data has been loaded to the second tire monitoring device and matches expected second configuration data; and
after receipt of both the first input and the second input, transmitting (<NUM>), by the untrusted device (<NUM>), a command initialising generation of a cryptographic parameter by the first tire monitoring device, and causing the cryptographic parameter to be exchanged with the second tire monitoring device such that secure future communication is established between the first and second tire monitoring devices.