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

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

When initially installed on the aircraft 100, the tire pressure monitoring devices 10,202,204,206,208,210 are not configured, ie do not store the configuration data 20, and are incapable of direct communication between one another. The user 24 therefore uses the untrusted device 32 to configure the network 200 of tire pressure monitoring devices 10,202,204,206,208,210, as will now be described.

Initially, the user 24 approaches the first tire pressure monitoring device 10 to begin configuration. The user 24 inputs the desired configuration data 20 for the first tire pressure monitoring device 10, including the wheel location and reference pressure, into the untrusted device 32, and the first tire pressure monitoring device 10 is touched with the untrusted device 32 to establish near field communication using the first transceiver 15. The desired configuration data 20 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 10 to the untrusted device 32. The configuration data 20 is then transferred from the untrusted device 32 to the first tire pressure monitoring device 10 via a Bluetooth® low energy protocol using the second transceiver 17 as previously described. The configuration data 20 is then stored in the memory 14, with the first tire pressure monitoring device 10 deleting any previously stored configuration data before the newly received configuration data 20 is stored. In other examples the configuration data 20 is transferred from the untrusted device 32 to the first tire pressure monitoring device 10 via near field communication.

Once the configuration data 20 has been stored, the processor 12 generates a key pair comprising a public key 212 and a private key 214, along with a random number 216, with use of these parameters described in more detail herein.

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

One piece of configuration data 20 to be checked is the installed location of the first tire pressure monitoring device 10. 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 18 which would correctly indicate the associated tire pressure monitoring device location. In the case of the first tire pressure monitoring device 10, which is used as the left nose tire pressure monitoring device in the example previously described, an appropriate flash sequence of the LED 18 may be one green flash, followed by five blue flashes, followed by one red flash. Illustrative appropriate flash sequences (ie signals 22) for tire pressure monitoring device location are shown schematically in FIG. 4.

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

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

Another piece of configuration data 20 to be checked is the stored reference pressure of the first tire pressure monitoring device 10. Here, as an example, an AMM task card may provide to the user 24 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 18 which would correctly indicate the associated tire pressure monitoring device reference pressure. In the case of the first tire pressure monitoring device 10, which is used as the left nose tire pressure monitoring device in the example previously described, an appropriate reference pressure may be 178 PSI. Here separate flash sequences of the LED 18 may be performed for each digit of the reference pressure, ie a first flash sequence/signal 22 for the “hundreds” digit, a second flash sequence/signal 22 for the “tens” digit, and a third flash sequence/signal 22 for the “units” digit. The first flash sequence of the LED 18 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 18 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 18 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 22) for tire pressure monitoring device reference pressure are shown schematically in FIG. 6.

When checking the stored reference pressure of the first tire pressure monitoring device 10, the user 24 submits a request for the first tire pressure monitoring device 10 to display the stored reference, via the LED 18, using a user interface of the untrusted device 32. The untrusted device 32 does not tell the first tire pressure monitoring device 10 which sequence to flash, but rather provides an instruction for the first tire pressure monitoring device 10 to flash its sequence indicative of the stored reference pressure. An exemplary user interface 60 for starting the check for the “hundreds” digit is shown in FIG. 7A, with the user 24 interacting with user interface element 62 to start the check for the “hundreds” digit. An exemplary user interface 64 for a user 24 to verify the signal 22 for the “hundreds” digit is shown in FIG. 7B, with the user 24 interacting with user interface elements 66,68 to indicate whether the signal 22 is verified or not.

Similarly an exemplary user interface 70 for starting the check for the “tens” digit is shown in FIG. 7C, with the user 24 interacting with user interface element 72 to start the check for the “tens” digit. An exemplary user interface 74 for a user 24 to verify the signal 22 for the “tens” digit is shown in FIG. 7D, with the user 24 interacting with user interface elements 76,78 to indicate whether the signal 22 is verified or not. An exemplary user interface 80 for starting the check for the “units” digit is shown in FIG. 7E, with the user 24 interacting with user interface element 82 to start the check for the “units” digit. An exemplary user interface 84 for a user to verify the signal 22 for the “units” digit is shown in FIG. 7F, with the user 24 interacting with user interface elements 86,88 to indicate whether the signal 22 is verified or not.

Once the desired configuration data 20 has been verified for the first tire pressure monitoring device 10, the user can move to the next tire pressure monitoring device 202,204,206,208,210 and perform the same steps to ensure configuration of each of the tire pressure monitoring devices 10,202,204,206,208,210.

As will be appreciated from the discussion above, during the process of configuring each tire pressure monitoring device 10,202,204,206,208,210, each tire monitoring device 10,202,204,206,208,210 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. 8, and these cryptographic parameters are utilised to establish secure communication within the network 200 of tire pressure monitoring devices 10,202,204,206,208,210. 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. 9, each tire pressure monitoring device 10,202,204,206,208,210, responsive to a command from the untrusted device 32, broadcasts, in a respective first message 218a-218f, its public key 212a-212f and its configuration data 20 to each of the other tire pressure monitoring devices 10,202,204,206,208,210. In other words, each tire pressure monitoring device broadcasts the first message to all of the other tire pressure monitoring devices. The untrusted device 32 is used as a router for the first messages 218a-218f, with each tire pressure monitoring device 10,202,204,206,208,210 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 17 of each tire pressure monitoring device 10,202,204,206,208,210, using a BLE protocol. Once all first messages 218a-218f are sent and received, each tire pressure monitoring device 10,202,204,206,208,210 knows the public key 212a-212f and configuration data 20 of each other tire pressure monitoring device 10,202,204,206,208,210. By broadcasting the first messages 218a-218f from the tire pressure monitoring devices 10,202,204,206,208,210, a number of messages sent by each tire pressure monitoring device 10,202,204,206,208,210 may be reduced compared to, for example, an arrangement where each tire pressure monitoring device 10,202,204,206,208,210 unicasts its public key 212a-212f and/or its configuration data 20 to each other tire pressure monitoring device 10,202,204,206,208,210. 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. 9, 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. 10, the processor 12 of each tire pressure monitoring device 10,202,204,206,208,210 uses its own random number 216-216f, the public keys 212a-212f both generated and received by the tire pressure monitoring device 10,202,204,206,208,210, and its own configuration data 20, 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 10,202,204,206,208,210 broadcasts, in a second message 222a-222f, its respective cryptographic commitment 220a-220f to each of the other tire pressure monitoring devices 10,202,204,206,208,210.

The untrusted device 32 is used as a router for the second messages 222a-222f, with each tire pressure monitoring device 10,202,204,206,208,210 receiving the other second messages 222a-222f via the untrusted device 32. 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 17 of each tire pressure monitoring device 10,202,204,206,208,210, using a BLE protocol. Once all second messages 222a-222f are sent and received, each tire pressure monitoring device 10,202,204,206,208,210 knows the cryptographic commitment 220a-220f of each other tire pressure monitoring device 10,202,204,206,208,210. By broadcasting the second messages 222a-222f from the tire pressure monitoring devices 10,202,204,206,208,210, a number of messages sent by each tire pressure monitoring device 10,202,204,206,208,210 may be reduced compared to, for example, an arrangement where each tire pressure monitoring device 10,202,204,206,208,210 unicasts its cryptographic commitment 220a-220f to each other tire pressure monitoring device 10,202,204,206,208,210.

As a third step in establishing secure communication, illustrated schematically in FIG. 11, each tire pressure monitoring device 10,202,204,206,208,210 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 10,202,204,206,208,210. 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 17 of each tire pressure monitoring device 10,202,204,206,208,210, using a BLE protocol. Once all third messages 224a-224f are sent and received, each tire pressure monitoring device 10,202,204,206,208,210 can open and verify the cryptographic commitments 220a-220f received from the other tire pressure monitoring devices 10,202,204,206,208,210. By broadcasting the third messages 224a-224f from the tire pressure monitoring devices 10,202,204,206,208,210, a number of messages sent by each tire pressure monitoring device 10,202,204,206,208,210 may be reduced compared to, for example, an arrangement where each tire pressure monitoring device 10,202,204,206,208,210 unicasts its input 226a-226f to each other tire pressure monitoring device 10,202,204,206,208,210.

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 32. For example, the error message could be communicated using Bluetooth® or NFC to the untrusted device 32 for display by the untrusted device 32. 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 10,202,204,206,208,210 generates, for each other tire pressure monitoring device 10,202,204,206,208,210, 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 10,202,204,206,208,210 performing the generation, and the public key 212a-212f of the tire pressure monitoring device 10,202,204,206,208,210 for which generation is being performed.

Using the pseudo random generator, each tire pressure monitoring device 10,202,204,206,208,210 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 10,202,204,206,208,210 then generates, for each other tire pressure monitoring device 10,202,204,206,208,210, 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 10,202,204,206,208,210 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 10,202,204,206,208,210 sends its respective values to the other tire pressure monitoring devices 10,202,204,206,208,210, with each tire pressure monitoring device 10,202,204,206,208,210 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 32. For example the error message could be communicated using Bluetooth® or NFC to the untrusted device 32 for display by the untrusted device 32. 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 10,202,204,206,208,210 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 32 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 10,202,204,206,208,210 of the network 200, 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 10, 202, 204, 206, 208, 210.

Where secure communication has been established, the tire pressure monitoring devices 10,202,204,206,208,210 can be used to communicate to the user that each tire pressure monitoring device 10,202,204,206,208,210 shares the same security code. Here each tire pressure monitoring device 10,202,204,206,208,210 generates a numerical value, representing a security code, that can be communicated to the user 24 by flashing the LED 18 in a manner similar to that previously described in relation to the checks of configuration data 20. The numerical value in some examples comprises a truncated hash of the configuration data 20, 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 20, public keys 212a-212f and random numbers 216a-216f. Any suitable hash function can be used, such as SHA-3. As each of the tire pressure monitoring devices 10,202,204,206,208,210 knows the same configuration data 20, 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 10,202,204,206,208,210.

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 24 to fill in security codes indicated by the received signals 22. Similar to the signals for reference pressure discussed in relation to FIGS. 6 and 7A-7F, signals 22 indicative of security codes communicated by flashing the LEDs 18 of the tire pressure monitoring devices 10,202,204,206,208,210 may comprise three digits, with each digit, ie “hundreds”, “tens”, “units” flashed using a separate signal 22. Each separate signal 22 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 24. 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 32 may be used to initiate transmission of a signal 22, and to confirm once a signal 22 has been received by the user 24.

Where the security codes flashed by the LEDs 18 of each tire pressure monitoring device 10,202,204,206,208,210 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 200 of tire pressure monitoring devices 10,202,204,206,208,210 needs to take place.

Pseudo code illustrating the steps involved in establishing secure communication and checking security codes is illustrated in FIG. 12. Here PSD refers to a tire pressure sensing device 10,202,204,206,208,210, UDEV refers to the untrusted device 32, 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 20.

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

A method 300 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. 13.

The method 300 comprises generating 302, at each tire monitoring device, a public key, and broadcasting 304, from each tire monitoring device to each other tire monitoring device, the respective public keys. The method 300 comprises generating 306, at each tire monitoring device, a cryptographic commitment using the public keys generated and received by the respective tire monitoring device, and broadcasting 308, from each tire monitoring device to each other tire monitoring device, the respective cryptographic commitments. The method 300 comprises broadcasting 310, 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 312, at each tire monitoring device, the commitments received by the respective tire monitoring device using the respective inputs.

The method 300 comprises generating 314, 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