Verifying requests

Abstract

The invention provides an autonomous system for airside autonomous baggage vehicles whereby commands, such as baggage dolly move from location to baggage hall, can be verified to confirm the request originates from a trusted source. A number of nodes can verify the request, and a consensus can be formed, i.e. if a total number of yes votes exceeds a threshold. If each node keeps a local blockchain then all verified requests can be added. The invention comprises comparing 204 a candidate trusted value received with a request with a trusted value stored at each node of the plurality of nodes, generating 205 a yes vote if the candidate trusted value matches the trusted value stored at a respective node, and verifying 208 the request if the number of yes votes across the plurality of nodes exceeds a predetermined threshold. Trusted values may be a hash of data contained within a preceding request. Each node of the plurality of nodes may store the series of requests on a local blockchain stored on that node, with verified requests added to the local blockchain as they are verified.

Description

TECHNICAL FIELD The present invention relates to a method of verifying a series of requests within a system comprising a plurality of nodes, a system comprising a plurality of nodes, and a computer programme product. BACKGROUND It is desirable to maximise the security of a system comprising a plurality of nodes in which requests are sent to and between the nodes. An example of such a system is a system comprising a plurality of autonomous vehicles in which each autonomous vehicle forms a node. The system may comprise additional nodes, for example in the form of a central controller. Requests may be sent between the autonomous vehicles and from the central controller to the autonomous vehicles. The system may be employed in an airport environment and the autonomous vehicles may be autonomous airside vehicles configured transport baggage, cargo, and ground equipment within the airport environment. The requests may comprise commands to be carried out by the autonomous airside vehicles. It is desirable to mitigate against untrusted third parties intercepting the requests and gaining control of one or more of the autonomous airside vehicles. SUMMARY A first aspect of the invention provides a method of verifying a request within a system comprising a plurality of nodes, the method comprising: i) storing a trusted value at each node of the plurality of nodes; ii) receiving the request, the request comprising a candidate trusted value; iii) comparing the candidate trusted value with the trusted value stored at each node of the plurality of nodes; iv) generating a yes vote if the comparing at step iii) indicates that the candidate trusted value matches the trusted value stored at the respective node; and v) verifying the request if the number of yes votes generated at step iv) exceeds a predetermined threshold. A second aspect of the invention provides a method of verifying a series of requests within a system comprising a plurality of nodes, the method comprising: i) storing an initial trusted value at at least one node of the plurality of nodes; ii) receiving a first request in the series of requests, the first request comprising a candidate trusted value; iii) comparing the candidate trusted value received with the first request with the initial trusted value stored at the or each node of the plurality of nodes; iv) verifying the first request if the comparing at step iii) indicates that the candidate trusted value matches the initial trusted value stored at the or each node of the plurality of nodes; v) storing a new trusted value at at least one node of the plurality of nodes in response to verifying the first request; vi) receiving a subsequent request in the series of requests, the subsequent request comprising a candidate trusted value; vii) comparing the candidate trusted value received with the subsequent request with the new trusted value stored at the or each node of the plurality of nodes; and viii) verifying the subsequent request if the comparing at step vii) indicates that the candidate trusted value matches the new trusted value stored at the or each node of the plurality of nodes. A third aspect of the invention provides a method of verifying a series of requests within a system comprising a plurality of nodes, the method comprising: i) storing an initial trusted value at each node of the plurality of nodes; ii) receiving a first request in the series of requests, the first request comprising a candidate trusted value; iii) comparing the candidate trusted value received with the first request with the initial trusted value stored at each node of the plurality of nodes; iv) generating a yes vote if the comparing at step iii) indicates that the candidate trusted value matches the initial trusted value stored at the respective node; v) verifying the first request if the number of yes votes generated at step iv) exceeds a predetermined threshold; vi) storing a new trusted value at each node of the plurality of nodes in response to verifying the first request; vii) receiving a subsequent request in the series of request, the subsequent request comprising a candidate trusted value; viii) comparing the candidate trusted value received with the subsequent request with the new trusted value stored at each node of the plurality of nodes; ix) generating a yes vote if the comparing at step viii) indicates that the candidate trusted value matches the new trusted value stored at the respective node; and x) verifying the subsequent request if the number of yes votes generated at step ix) exceeds a predetermined threshold. The first aspect of the invention provides a method in which a consensus must be reached between a plurality of nodes in order to verify a request. As such, a malicious third party would need to gain control of enough of the nodes to force a consensus and gain control of the system. For example, where the predetermined threshold is half the total number of nodes of the plurality of nodes, a malicious third party would need to gain control of over half the nodes in order to gain control of the system as a whole. The second aspect of the invention provides a method in which a trusted value required to verify a request is updated such that a new trusted value is required to verify a subsequent request after a first request is verified. As such, if even a malicious third party was able to obtain the initial trusted value, they would not be able to maintain control of the system without obtaining the new trusted value. This increases the burden on a malicious third party thereby hindering and discouraging any attempt to gain control of the system. The third aspect of the invention combines the benefits of the first and second aspects of the invention. The following statements may apply to any of the first, second, or third aspects of the invention unless explicitly stated otherwise. At least one node of the plurality of nodes may be an autonomous vehicle. More than one node of the plurality of nodes may be an autonomous vehicle. A majority of the nodes of the plurality of nodes may be autonomous vehicles. At least one node of the plurality of nodes may be a central controller or a controller remote from a vehicle. The at least one autonomous vehicle may comprise at least one autonomous airside vehicle. It will be appreciated that ‘autonomous’ refers to a vehicle capable of operating in at least one autonomous mode, including a partial autonomous mode and / or a fully autonomous mode. In the first aspect of the invention, the method may comprise storing the request at at least one node of the plurality of nodes in response to verifying the request at step v). In the second aspect of the invention, the method may comprise storing the first request at at least one node of the plurality of nodes in response to verifying the first request at step iv) and / or storing the subsequent request at at least one node of the plurality of nodes in response to verifying the subsequent request at step viii). In the third aspect of the invention, the method may comprise storing the first request at at least one node of the plurality of nodes in response to verifying the first request at step v) and / or storing the subsequent request at at least one node of the plurality of nodes in response to verifying the subsequent request at step x). In each aspect of the invention, each node of the plurality of nodes may store the request or the series of requests locally on that node, with verified requests stored as they are verified. Each node of the plurality of nodes may store the request or the series of requests on a local ledger, such as a blockchain, stored on that node, with verified requests added to the local ledger as they are verified. As such, each node may store a copy of the same ledger. Each request of the series of requests may comprise a timestamp. This may allow for a chronological record of requests to be maintained. The request, or at least one request in the series of requests, may be generated by any node of the plurality of nodes. Alternatively, the request or at least one request in the series of requests may be generated by an external node from outside the system. The request, or at least one request in the series of requests, may comprise a command to be carried out by at least one node of the plurality of nodes. The method may comprise carrying out the command in response to verifying the or each request. Where at least one node of the plurality of nodes is an autonomous vehicle, the at least one node of the plurality of nodes that is to carry out the command may be the at least one autonomous vehicle. In one example, the command may be to cause the or each autonomous vehicle to travel from a first location to a second location. In addition to or alternatively to a command, the request, or at least one request in the series of requests, may comprise data representing the status of the system or one or more nodes of the plurality of nodes, for example the number of nodes in the system, a status of one or more nodes of the system, a payload associated with one or more nodes of the system etc. The request, or at least one request in the series of requests, may comprise one or more node identification values. The node identification value may be a node identification value of a node which generated the request and / or a node at which the request is initially received. Where the request comprises a command, the request may comprise a node identification value of a node intended to carry out the command. Where a node is an autonomous vehicle, the node identification value for that node may be a vehicle identification value. In the first and third aspects of the invention, the predetermined threshold may be a number equal to at least half the total number of nodes of the plurality of nodes. The predetermined threshold may be a number in the range of 50-100%, 50-60%, 60-70%, 70-80%, 80-90%, or 90-100% of the total number of nodes of the plurality of nodes. The predetermined threshold may be adjustable in dependence on one or more variables of the system. The one or more variables of the system may comprise a cyber threat level. For example, the predetermined threshold may be increased if a cyber threat level is increased. In this way, the method may remain robust when the risk of the system being compromised increases. The request, or at least one request in the series of requests, may comprise a digital signature. The method may comprise verifying the digital signature. The method may comprise verifying the digital signature prior to verifying the request. The method may comprise storing a public-private key pair at each node of the plurality of nodes. The public-private key pair may be unique to the respective node. The method may comprise digitally signing the request, or at least one request in the series of requests, using the private key of one of the public-private key pairs. The method may comprise storing each public key of each public-private key pair at each node of the plurality of nodes. The public keys may be stored on a local ledger, which may be a same local ledger on which the request or series of requests is stored. The digital signature may therefore be verified at each node of the plurality of nodes by finding the respective public key stored at the node and using the public key to verify the digital signature. The use of public and private keys further enhances the security of the method. In particular, the use of public and private keys inhibits attacks from nodes outside of the system which do not have access to valid private or public keys. The use of public and private keys may also enable the use of unsecured communication channels. The private key of the or each public-private key pair may be stored within a trusted execution environment or a secure enclave of the respective node. The digital signing of the request, or at least one request in the series of requests, using the private key of one of the public-private key pairs may take place within the trusted execution environment or secure enclave of the respective node. The use of a trusted execution environment or a secure enclave may prevent a malicious third-party from accessing the respective private key, and therefore prevent the third-party from generating a request which would appear to originate from a trusted node and in turn prevent the third-party from gaining control of the system. The method may comprise additional measures to inhibit a malicious-third party from gaining control of the system by gaining control of an individual node. For example, the method may comprise temporally resetting or refreshing data required to generate a request which would appear to originate from a trusted node. This may mitigate against brute-force attacks from malicious third-parties. This data may comprise the private key of the respective node, such that a new corresponding public is generated and shared with the other nodes when the private key is refreshed. The data may alternatively or additionally comprise the new trusted value. The method may comprise resetting or refreshing data required to generate a request which would appear to originate from a trusted node periodically, wherein the time period is selected to be shorter than a known period of time it would take to obtain the data via a brute force attack. In the second aspect of the invention, the method may comprise ix) storing a new trusted value at at least one node of the plurality of nodes in response to verifying the subsequent request. The method may comprise repeating steps vi) to viii) for at least one further subsequent request in the series of requests. The method may comprise repeating steps vii) and viii) only for selected requests in the series of requests. The method may comprise repeating steps vi) to ix) for at least one further subsequent request in the series of requests. The method may comprise repeating steps vii) and ix) only for selected requests in the series of requests. In the third aspect of the invention, the method may comprise xi) storing a new trusted value at each node of the plurality of nodes in response to verifying the subsequent request. The method may comprise repeating steps vii) to x) for at least one further subsequent request in the series of requests. The method may comprise repeating steps vii) to x) only for selected requests in the series of requests. The method may comprise repeating steps vii) to xi) for at least one further subsequent request in the series of requests. The method may comprise repeating steps vii) to xi) only for selected requests in the series of requests. Each further subsequent request may comprise a new trusted value. The steps of receiving a request comprising a candidate trusted value, comparing the candidate trusted value to the most recently stored new trusted value at each node of the plurality of nodes, generating votes based on the comparison, verifying the request based on the votes, and storing a new trusted value may be repeated for any number of subsequent requests in the series of requests. Trusted values may be stored on a local ledger at a respective node of the plurality of nodes. The local ledge may be a same local ledger on which the request or series of requests and / or private and public keys are stored. In the second aspect of the invention, the method may comprise repeating steps vii) and viii) only for selected requests in the series of requests. The method may comprise repeating steps vii) and ix) only for selected requests in the series of requests. In the third aspect of the invention, the method may comprise repeating steps viii) to x) only for selected requests in the series of requests. The method may comprise repeating steps viii) to xi) only for selected requests in the series of requests. Requests received between the selected requests may be verified automatically on receipt. Requests received between the selected requests may not comprise a candidate trusted value or, where applicable, a new trusted value. The selected requests may be requests between which at least a predetermined time period has elapsed. The predetermined time period may be 10 seconds, 30 seconds, 60 seconds, or any time interval as appropriate. This may help to reduce the computational burden of the system. Step iv) in the first or third aspect of the invention may comprise generating a no vote if the comparing at step iii) indicates that the candidate trusted value does not match the trusted value stored at the respective node. Step iv) in the first or third aspect of the invention may comprise storing the yes vote or the no vote generated at step iv) in association with the respective node. Step ix) in the third aspect of the invention may comprise generating a no vote if the comparing at step viii) indicates that the candidate trusted value does not match the new trusted value stored at the respective node. Step ix) in the third aspect of the invention may comprise storing the yes vote or the no vote generated at step ix) in association with the respective node. The method may comprise storing the yes vote or the no vote at at least one node of the plurality of nodes. The method may comprise storing the yes vote or the no vote at each node of the plurality of nodes. Votes may be stored on a local ledger at a respective node of the plurality of nodes. The local ledge may be a same local ledger on which the request or series of requests, private and public keys, and / or trusted values are stored. The yes vote or no vote generated for a particular node of the plurality of nodes may be weighted. For example, a vote generated for a node in the form of a central controller may be given more weight, i.e., may count for more than one vote, may be given more weight than a vote generated for a node in the form of an autonomous vehicle. The method may comprise identifying a node of the plurality of nodes as compromised if the yes vote or the no vote stored in association with the node is different to the yes vote or the no vote stored in association with each of a majority of the other nodes of the plurality of nodes for each of a predetermined number of requests in the series of requests. The method may comprise identifying a node of the plurality of nodes as compromised if a statistical voting measure of the node exceeds a predetermined threshold. The statistical voting measure may be a proportion of a predetermined number of requests in the series of requests for which the yes vote or the no vote stored in association with the node is different to the yes vote or the no vote stored in association with a predetermined number of the nodes of the plurality of nodes. The predetermined number of the nodes of the plurality of nodes may be a majority, such as more than half, of the nodes of the plurality of nodes, or it may be any acceptable number of the nodes. The statistical voting measure of a node exceeding a predetermined threshold may indicate that the node is compromised because it may indicate that a malicious third-party is attempting to manipulate the yes vote or no vote stored in association with the node. Where one or more requests of the series of requests comprises a timestamp, the timestamp of a request for which the yes vote or the no vote stored in association with the node is different to the yes vote or the no vote stored in association with a predetermined number of the nodes of the plurality of nodes can be used to determine the time or approximate time of an attempt to compromise the node. For example, the timestamp of the first request of the predetermined number of requests can be used to determine the time or approximate time of an attempt to compromise the node. The method may comprise indicating the number of nodes of the plurality of nodes in dependence on the number of yes votes and no votes generated for the request or at least one request in the series of requests. For example, the request or the series of requests may comprise a request which only requires generating a yes vote or a no vote for each of the plurality of nodes, i.e., the request does not require any additional action to be taken by any of the nodes, and the method may comprise indicating the number of nodes in the plurality of nodes based on the number of yes votes and no votes that are generated in response to the request. The method may also comprise indicating the number of nodes in the plurality of nodes in dependence on the number of yes votes and no votes generated for any other received request. In this way, the method provides additional functionality beyond verifying requests by enabling the number of nodes in the system to be tracked. The request, or at least one request in the series of requests, may comprise a request to remove at least one node from the plurality of nodes. The method may comprise removing the or each node from the plurality of nodes in response to verifying the request. The method may comprise identifying at least one node of the plurality of nodes as compromised, for example as described above. The request, or at least one request in the series of requests, may comprise a request to remove the or each compromised node from the plurality of nodes. The method may comprise removing the or each compromised node from the plurality of nodes in response to verifying the request. The method may comprise removing any node from the plurality of nodes where the comparison of a candidate trusted value and the trusted value stored at the node is considered to be unreliable for any reason, whether that be because the node has been compromised, the node has malfunctioned, or any other reason. This in turn improves the reliability of the method in verifying requests. The request, or at least one request in the series of requests, may comprise a request to add a node to the plurality of nodes. The method may comprise adding the node to the plurality of nodes in response to verifying the request. If the request is verified, the node to be added to the plurality of nodes may be considered a trusted node. Increasing the number of trusted nodes in the plurality of nodes improves the reliability of the method in verifying requests. The plurality of nodes may be a subset of a wider plurality of nodes. For example, the wider plurality of nodes may comprise a fleet of autonomous vehicles, each autonomous vehicle providing a node of the wider plurality of nodes, with the subset of nodes selected to verify requests according to the method of the first, second or third aspect of the invention. Compromised nodes may be removed from the subset and trusted nodes may be added to the subset to maintain the reliability of the system in verifying requests. Where votes are stored, the votes may be stored at each node of the wider plurality of nodes, in addition or alternatively to each node of the plurality of nodes which is a subset of the wider plurality of nodes. The method may comprise identifying at least one node of the plurality of nodes as compromised, for example as described above. The request, or at least one request in the series of requests, may comprise a request to shut down the or each compromised node. The method may comprise shutting down the or each compromised node in response to verifying the request. Shutting down a compromised node may help to prevent further attempts by a malicious third party to gain control of the system via that node. The request, or at least one request in the series of requests, may comprise a request to reinstate at least one node of the plurality of nodes after the or each node has been shut down. The method may comprise reinstating the at least one node in response to verifying the request. The at least one node may have been shut down because the or each node may have been identified as compromised, or for any other suitable reason. If the request is verified, the node may now be considered a trusted node. Increasing the number of trusted nodes in the plurality of nodes improves the reliability of the method in verifying requests. Reinstating the at least one node may comprise verifying the identity of the at least one node. Verifying the identity of the at least one node may comprise establishing a connection with a trusted server and / or a trusted node of the plurality of nodes. The connection may be wired or wireless. The method may comprise reinstating the at least one node only if one or more predetermined conditions are met. The one or more predetermined conditions may comprise the node being not currently operating. For example, where the node is an autonomous vehicle, the autonomous vehicle being not currently operating may mean that the autonomous vehicle is stationary and / or in a powered-down state. Reinstating or adding at least one node may comprise storing the most recent new trusted value at the or each reinstated or added node. In this way, the or each reinstated or added node can be used in the method of the first, second or third aspect of the invention to verify newly received requests. Reinstating or adding at least one node may comprise storing all previous trusted values and / or requests of the series of requests at the or each reinstated or added node. This allows for an up-to-date record of trusted values and / or requests to be maintained at each node of the plurality of nodes. The request, or at least one request in the series of requests, may comprise only the candidate trusted value and the new trusted value. The request may comprise the candidate trusted value, the new trusted value and other data, such as a node identification value, a nonce and / or a timestamp, but may not comprise a command to be carried out by at least one node of the plurality of nodes. The purpose of the request may therefore be only to ‘refresh’ the trusted value stored at each node of the plurality of nodes. The candidate trusted value may be intentionally different to the previous trusted value such that the comparison of the candidate trusted value and the previous trusted value should result in a no vote being generated in association with each node of the plurality of nodes or at least a predetermined number of nodes of the plurality of nodes. This may be used to ensure that the method is still capable of generating no votes and may be used to identify compromised nodes for which a yes vote may be generated in such situations. The request, or at least one request in the series of requests, may comprise the new trusted value. The new trusted value may therefore be received alongside the candidate trusted value as part of the request. Step v) of the second aspect of the invention and step vi) of the third aspect of the invention may comprise storing the request. Receiving the new trusted value alongside the candidate trusted value helps to minimise the number of transmissions within the system, which in turn minimises the number of opportunities for a malicious third party to gain control of the system. In the second and third aspects of the invention, a new trusted value may be a hash of data and / or metadata contained in the most recently received request. Any suitable hash function may be used to generate the hash. Where a request comprises a new trusted value, the new trusted value may be a hash of data and / or metadata contained in the request comprising the new trusted value. In the second aspect of the invention, the new trusted value stored at step v) may be a hash of data and / or metadata contained in the first request. In the third aspect of the invention, the new trusted value stored at step vi) may be a hash of data and / or metadata contained in the first request. Where applicable, the new trusted value stored at step ix) of the method of the second aspect of the invention or the new trusted value stored at step xi) of the method of the third aspect of the invention may be a hash of data and / or metadata contained in the most recently received further subsequent request. In other embodiments, the new trusted value may not be a hash and may instead be a random sequence of values, a password or the like. The request, or at least one request in the series of requests, may comprise a time stamp. A time stamp enables a record of requests to be maintained. This enables monitoring of the system, for example to determine when a particular node has been compromised, removed from the plurality of nodes or shut down. In turn, when a node is reinstated or added to the plurality of nodes, the status of the node can be updated from when it was removed or shut down. In addition, or alternatively to a time stamp, the request or at least one request in the series of requests may comprise a count which has increased from a previous request. The request or at least one request in the series of requests may comprise any suitable data which allows the point in time at which the request was generated and / or received to be determined. The method may comprise periodically deleting all stored trusted values. Where requests are stored, the method may comprise periodically deleting all stored requests. The method may comprise periodically deleting all stored trusted values and / or requests daily or at the start or end of a shift, for example. The request, or at least one request in the series of requests, may comprise a request to delete all stored trusted values and / or requests. The method may be essentially restarted periodically. Periodically deleting stored trusted values helps to manage the data storage capacity of the system. The method may comprise adding nodes to and / or removing nodes from the plurality of nodes in dependence on one or more variables. The one or more variables may include time and / or a location of one or more nodes. This may help to ensure that only nodes which can be reliably used to verify requests are used in the method, thereby maximising the overall reliability of the method in verifying requests. A fourth aspect of the invention provides a system comprising a plurality of nodes, wherein the system is configured to carry out the method of any of the first, second or third aspects of the invention. At least one node of the plurality of nodes may be an autonomous vehicle. More than one node of the plurality of nodes may be an autonomous vehicle. A majority of the nodes of the plurality of nodes may be autonomous vehicles. At least one node of the plurality of nodes may be a central controller or a controller remote from a vehicle. The at least one autonomous vehicle may comprise at least one autonomous airside vehicle. A fifth aspect of the invention provides a computer programme product comprising instructions stored on a computer-readable medium configured to carry out the method of any of the first, second or third aspects of the invention when the computer programme product is run on a computer. BREIF DESCRIPTION OF THE DRAWINGS Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, as follows: Figure 1 shows a system comprising a plurality of nodes according to an embodiment of the invention; Figure 2a shows a computer-implemented method of verifying a series of requests within a system comprising a plurality of nodes according to an embodiment of the invention; Figure 2b shows a computer-implemented method of verifying a series of requests within a system comprising a plurality of nodes according to another embodiment of the invention; Figure 3 illustrates an implementation of some of the steps of the method of Figure 2a or the method of Figure 2b; Figure 4a illustrates an example data structure of a request as received in the method of Figure 2a or the method of Figure 2b according to an embodiment of the invention; Figure 4b illustrates a first request and a subsequent request of a series of requests as verified using the method of Figure 2a or the method of Figure 2b according to an embodiment of the invention: Figure 4c illustrates further subsequent requests in the series of requests of Figure 4b; Figure 4d illustrates further subsequent requests in the series of requests of Figure 4b; Figure 5 illustrates the implementation of Figure 3 of the method of Figure 2a with the requests of Figure 4c; and Figures 6a to 6c illustrate a process of removing and adding a node from the plurality of nodes of the system of Figure 1 using the method of Figure 2a. DETAILED DESCRIPTION Figure 1 shows a system 10 according to an embodiment of the invention. The system comprises a plurality of nodes 100. The plurality of nodes 100 comprises a central controller 101, two sub-controllers 102a, 102b, and three autonomous vehicles 103a-c. In other embodiments, the plurality of nodes 100 may comprise any suitable number and type of nodes, such as controllers, processors, and devices. In one embodiment, the system 10 is an airport system and each of the autonomous vehicles 103a-c comprises an airside autonomous vehicle, such as an airside autonomous baggage or cargo dolly, an autonomous dolly tug, an autonomous equipment transportation vehicle, or an autonomous passenger transport vehicle. Figure 2a shows a computer-implemented method 200 of verifying a series of requests within a system comprising a plurality of nodes according to an embodiment of the invention. In the present embodiment, the system is the system 10 of Figure 1, but the method 200 is applicable to any suitable system. The method 200 begins at step 201. At step 201, an initial trusted value and a publicprivate key pair is stored at each node of the plurality of nodes 100. At step 202, a request is received at one of the nodes of the plurality of nodes 100. The request comprises a digital signature and the digital signature is verified using the public key-stored at the node that has received the request. The private key stored at each node of the plurality of nodes 100 allows new requests to be generated and digitally signed using the private key at each node of the plurality of nodes 100. Other embodiments may not utilise public-private key pairs or digital signatures. In embodiments that employ digital signing of requests, if a request is not accompanied by a verified digital signature, the request may not be verified, e.g., the request may be rejected or ignored. The request comprises a command to be carried out by the node receiving the request. In other embodiments, the request may not comprise a command and instead the only-purpose of the request may be to store the new trusted value at each node of the plurality of nodes 100 if the request is verified. In the example of an airport system, the node receiving the request may be one of the airside autonomous vehicles 103a-c comprising an autonomous baggage dolly, and the command may require the autonomous baggage dolly to travel from its current location to a baggage hall. Other types of command may be comprised in the request; for example, one or more commands relating to adding a new node to the plurality of nodes or removing an existing node from the plurality of nodes, as described below with reference to Figures 6a-c, may be comprised in a request. Before the node receiving the request carries out the command, it is desirable for the request including the command to be verified, i.e., to confirm that the request originates from a trusted source, such as the central controller 101 or one of the sub-controllers 102a, 102b. Although the digital signature provides some indication of authenticity of the request, it is desirable to further verify the request. In addition to the command, the request comprises a candidate trusted value and a new trusted value. At step 203, the request is transmitted to each other node of the plurality of nodes 100, such that each node of the plurality of nodes 100 receives the candidate trusted value and the new trusted value. In some embodiments each request may be broadcast to all nodes, for example each request may be re-transmitted from the node that receives the request to other nodes that are in range. In some embodiments, the request may not be transmitted to each other node of the plurality of nodes 100, but instead to a subset of the other nodes which comprises fewer than all of the other nodes. For example, some of the nodes of the plurality of nodes 100 may not be able to receive transmissions due to being out of service, out of communication range, or otherwise unavailable, or sufficient verification may be achievable by transmitting the request to a subset of nodes. At step 204, the candidate trusted value is compared with the initial trusted value stored at each node of the plurality of nodes 100. At each node of the plurality of nodes 100, a comparison is carried out between the candidate trusted value and the initial trusted value as stored at the respective node. At step 205, a yes vote is generated at each node of the plurality of nodes 100 where the comparison at step 204 indicates that the candidate trusted value matches the initial trusted value stored at the respective node. At step 206, a no vote is generated at each node of the plurality of nodes 100 where the comparison at step 204 indicates that the candidate trusted value does not match the initial trusted value stored at the respective node. In other embodiments, step 206 may be omitted, and instead a vote is not generated if the comparison at step 204 indicates that the candidate trusted value does not match the initial trusted value stored at the respective node. At step 207, each node of the plurality of nodes 100 transmits its yes vote or no vote (generated at the respective node) to each of the other nodes of the plurality of nodes 100. As such, each node of the plurality of nodes 100 collates all of the yes votes and no votes, are generated at steps 205 and 206, that it receives. In this embodiment, all of the yes votes and no votes generated at steps 205 and 206 and received at each respective node are stored by that node. Each vote is stored in association with the node at which the vote was generated, at each node of the plurality of nodes 100. Each node therefore stores a record of votes. In other embodiments the votes may not be stored. At step 208, the total number of yes votes is determined by at least one node of the plurality of nodes 100, and if the total number of yes votes exceeds a predetermined threshold, such as 90% of the total votes, then the request is verified. If the total number of yes votes does not exceed the predetermined threshold, then the request is not verified. In some embodiments, each node will perform its own determination of when the total number of yes votes exceeds the threshold for verification. In other embodiments, step 207 may comprise each node of the plurality of nodes 100 transmitting the yes vote or the no voted generated at the respective node to: only one node of the plurality of nodes 100, for example the node that received the request; or more than one node of the plurality of nodes 100 but less than all of the other nodes of the plurality of nodes 100, to enable step 208 to be carried out. If the request is verified, the method 200 proceeds to steps 209 and 210. At step 209, the new trusted value is stored at each node of the plurality of nodes 100. At step 210, the command is carried out by the node that received the request. Although illustrated separately in Figure 2a, it will be appreciated that steps 209 and 210 may happen concurrently or sequentially (in either order). After steps 209 and 210, and after step 208 if the request is not verified, the method 200 returns to step 202 at which the next request in the series of requests is received. Steps 202 to 210 are then repeated as required for subsequent requests in the series of requests, with the candidate trusted value received with a request being compared to the new trusted value of the previously verified requests as stored at each node of the plurality of nodes 100. In some embodiments, not every request may need to be fully verified. For example, it may be sufficient to ensure that requests are verified after a specific time has elapsed since the previous such verification (on the basis that only so much can go wrong in a relatively short period of time). In some embodiments, only selected requests are subject to verification. Figure 2b shows a computer-implemented method 2000 of verifying a series of requests within a system comprising a plurality of nodes according to another embodiment of the invention in which only selected requests are subject to full verification. The method 2000 of Figure 2b comprises all the steps of the method 200 of Figure 2a with the same reference numerals used to refer to the same steps. The method 2000 of Figure 2b differs from the method 200 of Figure 2a in that the method 2000 of Figure 2b comprises step 211. At step 211, it is determined whether the request received at step 202 is a selected request. If the request is a selected request, the method 2000 proceeds with steps 203 to 210. If the request is not a selected request the method 2000 skips steps 203 to 209 and proceeds straight to step 210. In this embodiment, a request is a selected request if at least a predetermined time period since the last request for which steps 203 to 210 where carried has elapsed. A request received at step 202 which is not a selected request need not necessarily include a candidate trusted value or a new trusted value (but may do so). Although in the above embodiments the new trusted value is received as part of the request, in other embodiments the request may not comprise the new trusted value and the new trusted value may be received separately from the request at any stage before step 209 of the method. Although the methods 200, 2000 described above with certain steps being carried out certain entities of the system 10, it will be appreciated that in other embodiments, steps 202 to 208 may be carried out at any suitable entity, whether that be an entity of the system 10 or an entity outside of the system 10. For example, requests could be received and verified at one of the sub-controllers 102a, 102b, with verified requests being sent to one or more of the plurality of nodes 100 as appropriate to carry out the command included in the request. A request could be transmitted to each node of the plurality of nodes 100 as an initial step, rather the request being first received at a node of the plurality of nodes 100 and then transmitted from that node to each other node of the plurality of nodes 100. In addition, although the methods 200, 2000 are described above with the steps being carried out in a particular order, the steps may be carried out in a different order in other embodiments where appropriate. Figure 3 illustrates an implementation of some of the steps of the method 200 of Figure 2a or the method 2000 of Figure 2b. Figure 3 shows the three autonomous vehicles 103a-c of the plurality of nodes of the system of Figure 1. In the example of Figure 3, autonomous vehicle 103b receives a request at step 202 of the method 200. At step 203 of the method 200, the autonomous vehicle 103b transmits the request to each of the other autonomous vehicles 103a, 103c, as indicated by the solid arrows, as well as to the central controller and the two sub-controllers (not shown). At step 207 of the method 200, each of the autonomous vehicles 103a-c transmits the yes vote or the no vote generated at the respective autonomous vehicle 103a-c (at steps 205 and 206 of the method 200) to each of the other nodes of the system. The transmission of the yes vote or the no vote generated at autonomous vehicles 103a, 103b to autonomous vehicle 103b is illustrated by the dotted arrows in Figure 3. The transmission of the yes vote or the no vote generated at autonomous vehicle 103a to autonomous vehicle 103c, the transmission of the yes vote or the no vote generated at autonomous vehicle 103c to autonomous vehicle 103a, and the transmission of the yes vote or the no vote generated at autonomous vehicle 103b to each of autonomous vehicles 103a, 103c is illustrated by the dashed arrows in Figure 3. As illustrated by the dotted arrows and the dashed arrows in Figure 3, the yes vote or the no vote generated at each of autonomous vehicle 103a and autonomous vehicle 103c are not just transmitted to autonomous vehicle 103b, i.e., the autonomous vehicle that initially received the request to be verified, but also to each of the other nodes of the system. Each node (e.g., vehicle) may store a sequence of requests on a blockchain stored on that node, with verified requests added to the local blockchain as they are verified. A blockchain approach provides for a non-mutable record of prior verified requests, which has certain advantages in the context of the invention. Figure 4a illustrates an example data structure of a request 30 as received at step 202 of the method 200 of Figure 2a or the method 2000 of Figure 2b according to an embodiment of the invention. The request 30 (which may also be considered a data block) comprises five data elements 301 to 305. These comprise: timestamp 301, nonce 302, command 303, candidate trusted value 304, and new trusted value 305 is configured to represent a new trusted value. In this embodiment, the new trusted value 305 is a hash of the current request (or block) 30, exclusive of the new trusted value 305. The candidate trusted value 304 is a candidate of the hash of the previous request or block. In some embodiments, at least some requests 30 may omit the command 303 and / or the candidate trusted value 304, i.e., data elements 303 and / or 304 may be equivalent to zero. In some embodiments, data element 303 may include data other than a command, such as data representing the status of the system 10. In other embodiments, the request 30 may include additional data elements. Figure 4b illustrates a first request 30a and a subsequent request 30b of a series of requests as verified using the method 200 of Figure 2a or the method 2000 of Figure 2b according to an embodiment of the invention. Each of the first request 30a and the subsequent request 30b comprises the data structure of the request 30 of Figure 4a. The same reference numerals are used in Figure 4b to refer to the same elements of the first request 30a and the subsequent request 30b as the elements of the request 30 of Figure 4a, with the suffix ‘a’ and ‘b’ used to refer to elements of the first request 30a and the subsequent request 30b respectively. The data elements 303a and 304a of the first request 30a, comprising a command and a candidate trusted value, respectively, are each equivalent to zero. The dashed line in Figure 4b illustrates the comparison at step 204 of the method 200, where the candidate trusted value 304b of the subsequent request 30b is compared with the trusted value 305a of the first request 30b as stored at each node of the plurality of nodes 100 of the system 10. Step 209 of the method 200 comprises storing the new trusted value 305b of the subsequent request 30b by storing the whole of subsequent request 30b. In this embodiment, to generate a yes vote a new request / block must include a hash of the previous block that agrees with a locally stored hash of the previous block. A consensus yes vote (exceeding a threshold) results in the new request being verified and written to the local blockchain of each node. Figure 4c illustrates further subsequent requests 30c-30e in the series of requests of Figure 4b. Each of the requests 30a-e of Figure 4c comprises the data structure of the request 30 of Figure 4a. The same reference numerals are used in Figure 4c to refer to the same elements of the requests 30a-e as the elements of the request 30 of Figure 4a, with the suffixes ‘a’ to ‘e’ used to refer to elements of the respective requests 30a-e. For clarity, not every element of the requests 30a-e of Figure 4c is labelled. In the example of Figure 4c, the method 200 of Figure 2a is employed, with the comparison at step 204 of the method 200 indicated by dashed lines. Each subsequent request is stored at step 209 of the method 200. A blockchain comprising previous requests can thereby be locally stored at each node. Nodes that share the same blockchain will be in agreement about the hash of the previous block, and will therefore reach consensus on whether the candidate trusted value in a new request / block matches the hash of the previous request / block. Figure 4d illustrates further subsequent requests 30c-30e in the series of requests of Figure 4b. Each of the requests 30a-e of Figure 4c comprises the data structure of the request 30 of Figure 4a. The same reference numerals are used in Figure 4c to refer to the same elements of the requests 30a-e as the elements of the request 30 of Figure 4a, with the suffixes ‘a’ to ‘e’ used to refer to elements of the respective requests 30a-e. For clarity, not every element of the requests 30a-e of Figure 4c is labelled. In the example of Figure 4d, the method 2000 of Figure 2b is employed, with the comparison at step 204 of the method 200 indicated by dashed lines. In the example of Figure 4d, requests 30b and 30e are selected requests and requests 30c and 30d are not selected requests. Requests 30c and 30d are not written to the blockchain at each node. Steps 203 to 210 are carried out for requests 30b and 30e, but the method 2000 skips steps 203 to 209 after requests 30c and 30d are received at step 202. Requests 30c and 30d are therefore not stored, and the comparison at step 204 after request 30e is received at step 202 is carried out between the candidate trusted value 304e of request 30e (i.e., the last block that has been written to the blockchain) and the new trusted value 305b of request 30b. Figure 5 illustrates the implementation of Figure 3 of the method 200 of Figure 2a with the requests 30a-e of Figure 4c. For clarity, the features of the requests 30a-e are not labelled in Figure 5. As shown in Figure 5, each verified request is stored at each of the autonomous vehicles 103a-c, as well as at each other node of the plurality of nodes (not shown). Figures 6a to 6c illustrate a process of removing and adding a node from the plurality of nodes 100 of the system 10 of Figure 1 using the method 200 of Figure 2a. In this example, autonomous vehicle 103b has been identified as compromised, as indicated by the dashed line in Figure 6a. In other examples, autonomous vehicle 103b may not be identified as compromised, but instead may be identified as being unavailable for receiving requests, for example because the autonomous vehicle 103b is outside of communication range of the other nodes of the plurality of nodes 100. In this example, the record of votes stored at one or more nodes of the plurality of nodes indicates that the yes vote or the no vote stored in association with autonomous vehicle 103b is different to the yes vote or the no vote stored in association with each of a majority of the other nodes of the plurality of nodes for each of a predetermined number of requests in the series of requests. To put it another way, a compromised node may vote against the majority as to whether a new block should be written to the block chain, for one or more new blocks in row, and thereby be identified as compromised. A node that has a blockchain which is missing one or more verified requests, or which comprises a request that has not been verified by consensus with the other nodes (which could be the case for a compromised node), will have a hash value for the latest block that is not agreement with the uncompromised other nodes. A compromised node may consistently vote against the other nodes in verification for this reason (because a new block cannot be written to that node without breaking the consistency of hashing in the blockchain on that node). In other examples, autonomous vehicle 103b may be identified as compromised by any other suitable means. In the event a node is found to be compromised, the state of the local blockchain on that node can be stored before deletion and compared with that of a healthy node to detect the time and content of any attack leading to compromise (or to identify any disturbance that may have resulted in compromise, such as a particular event or location that might result in loss of communication). Nodes can be added and deleted from the wider node population by using the voting power of the population (as described herein) to agree that a request for node deletion or addition is authentic. To compromise the whole population, more than half the population needs to be simultaneously compromised. In node removal, the method 200 begins at step 202 with a request to remove autonomous vehicle 103b from the plurality of nodes, i.e., the command of the request is a command to remove autonomous vehicle 103b from the plurality of nodes, being received at one of the nodes of the plurality of nodes. Steps 203 to 208 of the method are then carried out. If the request is verified at step 208, then the autonomous vehicle 103b is removed from the plurality of nodes at step 210, as indicated by the dotted line in Figure 6b. A node can be brought back up to date with the valid blockchain by copying the correct state of the blockchain from the voting population. Once autonomous vehicle 103b is deemed to be no longer compromised (e.g. after blockchain restoration from another node that agrees with the consensus blockchain), the method 200 is repeated with a request to add autonomous vehicle 103b back into the plurality of nodes. If the request is verified at step 208, then the autonomous vehicle 103b is added back to the plurality of nodes at step 210, as indicated by the solid line in Figure 6c. In this example, step 209 is carried out once the autonomous vehicle 103b is added back to the plurality of nodes, such that the request, which comprises the most recent new trusted value, is stored at the autonomous vehicle 103b, as well as each other node of the plurality of nodes. Any previous requests and / or trusted values which were not stored at the autonomous vehicle 103b while the autonomous vehicle was absent from the plurality of nodes may also be stored at the autonomous vehicle 103b. In the same way as autonomous vehicle 103b is added back to the plurality of nodes, a brand new node can be added to the plurality of nodes. The population of nodes can thereby be made self-healing, in that nodes that go offline or are otherwise compromised can be re-initialised with the correct consensus state. The locally stored blockchains can be purged or cleared periodically, for example daily or on demand (e.g., due to excessive threat detection etc). It will be appreciated that the examples described above are purely illustrative and that different examples falling within the scope of the claims are possible. The scope of the invention should be determined with reference to the claims.

Claims

1. A computer-implemented method of verifying a series of requests within a system comprising a plurality of nodes, wherein at least one node of the plurality of nodes is an autonomous vehicle, the method comprising:i) storing an initial trusted value at each node of the plurality of nodes;ii) receiving a first request in the series of requests, the first request comprising a candidate trusted value;iii) comparing the candidate trusted value received with the first request with the initial trusted value stored at each node of the plurality of nodes;iv) generating a yes vote if the comparing at step iii) indicates that the candidate trusted value matches the initial trusted value stored at the respective node;v) verifying the first request if the number of yes votes generated at step iv) exceeds a predetermined threshold;vi) storing a new trusted value at each node of the plurality of nodes in response to verifying the first request;vii) receiving a subsequent request in the series of requests, the subsequent request comprising a candidate trusted value;viii) comparing the candidate trusted value received with the subsequent request with the new trusted value stored at each node of the plurality of nodes;ix) generating a yes vote if the comparing at step viii) indicates that the candidate trusted value matches the new trusted value stored at the respective node; andx) verifying the subsequent request if the number of yes votes generated at step ix) exceeds a predetermined threshold.

2. The method of claim 1, wherein each node of the plurality of nodes stores the series of requests on a local blockchain stored on that node, with verified requests added to the local blockchain as they are verified.

3. The computer-implemented method of claim 1 or 2, wherein at least one request in the series of requests comprises a command to be carried out by at least one node of the plurality of nodes, and wherein the method comprises carrying out the command in response to verifying the or each request.

4. The computer-implemented method of claim 3, wherein the at least one node of the plurality of nodes that is to carry out the command is the at least one autonomous vehicle and / or an autonomous airside vehicle5. The computer-implemented method of any preceding claim, wherein at least one request in the series of requests comprises a digital signature, wherein the method comprises verifying the digital signature.

6. The computer-implemented method of any preceding claim, comprising xi) storing a new trusted value at each node of the plurality of nodes in response to verifying the subsequent request, and repeating steps vii) to x), and optionally steps vii) to xi), for at least one further subsequent request in the series of requests.

7. The computer-implemented method of claim 6, wherein each further subsequent request comprises a new trusted value.

8. The computer-implemented method of any preceding claim, comprising repeating steps viii) to x), and optionally steps viii) to xi), only for selected requests in the series of requests, wherein the selected requests are requests between which at least a predetermined time period has elapsed.

9. The computer-implemented method of any preceding claim, wherein step iv) comprises: generating a no vote if the comparing at step iii) indicates that the candidate trusted value does not match the initial trusted value stored at the respective node, and storing the yes vote or the no vote generated at step iv) in association with the respective node; and / or wherein step ix) comprises: generating a no vote if the comparing at step viii) indicates that the candidate trusted value does not match the new trusted value stored at the respective node, and storing the yes vote or the no vote generated at step ix) in association with the respective node.

10. The computer-implemented method of claim 9, comprising storing the yes vote or the no vote at at least one node of the plurality of nodes.

11. The computer-implemented method of claim 10, comprising identifying a node of the plurality of nodes as compromised if a statistical voting measure of the nodeexceeds a predetermined threshold, wherein the statistical voting measure is a proportion of a predetermined number of requests in the series of requests for which the yes vote or the no vote stored in association with the node is different to the yes vote or the no vote stored in association with a predetermined number of the nodes of the plurality of nodes.

12. The computer-implemented method of any of any preceding claim, comprising indicating the number of nodes in the plurality of nodes in dependence on the number of yes votes and no votes generated for a given request in the series of requests.

13. The computer-implemented method of any preceding claim, wherein at least one request in the series of requests comprises a request to remove at least one node from the plurality of nodes, and where the method comprises removing the or each node from the plurality of nodes in response to verifying the request.

14. The computer-implemented method of claim 13, comprising identifying at least one node of the plurality of nodes as compromised, wherein the at least one request in the series of requests comprises a request to remove the or each compromised node from the plurality of nodes, and where the method comprises removing the or each compromised node from the plurality of nodes in response to verifying the request.

15. The computer-implemented method of any preceding claim, wherein at least one request in the series of requests comprises a request to add a node to the plurality of nodes, and wherein the method comprises adding the node to the plurality of nodes in response to verifying the request.

16. The computer-implemented method of any preceding claim, comprising identifying at least one node of the plurality of nodes as compromised, wherein at least one request in the series of requests comprises a request to shut down the or each compromised node, and wherein the method comprises shutting down the or each compromised node in response to verifying the request.

17. The computer-implemented method of any preceding claim, wherein at least one request in the series of requests comprises a request to reinstate at least one node of theplurality of nodes after the or each node has been shut down, and wherein the method comprises reinstating the at least one node in response to verifying the request.

18. The computer-implemented method of claim 17, wherein reinstating the at least one node comprises storing the most recent new trusted value at the or each reinstated node.

19. The computer-implemented method of any preceding claim, wherein at least one request in the series of requests comprises only the candidate trusted value and the new trusted value, and optionally a time stamp.

20. The computer-implemented method of any preceding claim, wherein the first request comprises the new trusted value, and wherein step vi) comprises storing the first request.

21. The computer-implemented method of any preceding claim, wherein the new trusted value is a hash of data and / or metadata contained in the first request.

22. The computer-implemented method of any preceding claim, wherein at least one request in the series of requests comprises a time stamp.

23. The computer-implemented method of any preceding claim, comprising periodically deleting all stored trusted values.

24. The computer-implemented method of any preceding claim, comprising adding nodes to and / or removing nodes from the plurality of nodes in dependence on one or more variables, optionally wherein the one or more variables include time and / or a location of one or more nodes.

25. A system comprising a plurality of nodes, wherein at least one node of the plurality of nodes is an autonomous vehicle, and wherein the system is configured to carry out the method of any preceding claim.

Images