GB2551808A

GB2551808A - Data validation

Info

Publication number: GB2551808A
Application number: GB1611456.3A
Authority: GB
Inventors: James Cowan Alexander
Original assignee: Razorsecure Ltd
Current assignee: Razorsecure Ltd
Priority date: 2016-06-30
Filing date: 2016-06-30
Publication date: 2018-01-03
Also published as: GB201611456D0

Abstract

Method of validating data, e.g. an executable instruction, comprises: receiving data via a first route; receiving a verification of said data via a second route, wherein said routes are independent of one another; and determining from said verification of said data whether said data is valid. System for validating data comprises first and second subsystems and a plurality of independent routes wherein the first subsystem receives data from the second subsystem via a first route and requests a verification of said data via a second route. Confirmation may be sent via a third route. An alert may be issued to a central server or user if data is determined to be invalid. The alert may be sent via two independent routes which comprise physically independent Application Program Interfaces APIs 104 selected from a pool of API servers by a load balancer in dependence on security status, ping time, round-robin or geographic location. New instructions may be periodically checked for using an info push. May be used to send data securely and redundantly to a remote system 102 which relies on noisy or unreliable data connections to a central server 106.

Description

(54) Title of the Invention: Data validation

Abstract Title: Validation of data sent via multiple routes between a central server and a remote system (57) Method of validating data, e.g. an executable instruction, comprises: receiving data via a first route; receiving a verification of said data via a second route, wherein said routes are independent of one another; and determining from said verification of said data whether said data is valid. System for validating data comprises first and second subsystems and a plurality of independent routes wherein the first subsystem receives data from the second subsystem via a first route and requests a verification of said data via a second route. Confirmation may be sent via a third route. An alert may be issued to a central server or user if data is determined to be invalid. The alert may be sent via two independent routes which comprise physically independent Application Program Interfaces APIs 104 selected from a pool of API servers by a load balancer in dependence on security status, ping time, round-robin or geographic location. New instructions may be periodically checked for using an info push. May be used to send data securely and redundantly to a remote system 102 which relies on noisy or unreliable data connections to a central server 106.

1/3

102

Figure 1

102 106

2/3

Figure 2

3/3

Figure 3

- 1 Data validation

Field of invention

This invention relates to a data validation system, method and apparatus, in particular for securely validating instructions sent to a remote processor.

Background

Remote processing systems such as in-flight entertainment systems or train control systems rely on a data connection to a central control server which may be noisy or unreliable. Furthermore, the data connection may become compromised by third parties (i.e. hackers) who may ‘spoof instructions or otherwise take control of the remote processing system.

An improved method for ensuring that the data being processed by the remote system is legitimate is required.

According to one aspect of the present invention there is provided a method of validating data, the method comprising: receiving data via a first route (from a first Application

Program Interface (API)); receiving a verification of said data via a second route (from a second API), wherein said first and second routes are independent of one another; and determining from said verification of said data whether said data is valid. In such a way, data may be validated in a secure, redundant and robust manner.

For security, an alert may be sent to a central server if it is determined that said data is not valid.

For security, the method may further comprise outputting an alert to a user.

For redundancy and so as to reduce the effect of compromised or unavailable routes, said alert is sent to the central server via two independent routes. The two independent routes may comprise a third route.

-2For ease of use and efficiency, said routes each comprise an Application Program Interface (API).

For protection against simultaneous failure, said APIs are physically independent API servers.

For protection against simultaneous failure, said APIs are separated by software.

For redundancy and/or security, the method may comprise selecting said API servers from a pool of API servers.

For security, the method may comprise selecting a replacement API server from a pool of API servers in the event of a compromise or failure of an API server.

So as to avoid overloading one part of the system, the API server is selected by a load balancer. The load balancer may select the API server in dependence on at least one of security status, ping time, round-robin, and geographic location of said API server. In such a way the appropriate API may be selected so as to provide the optimum performance, which may be speed of communication, security, or fidelity of data.

For security the method may comprise testing said selected API server for validity and/or operation.

For security the method may comprise negotiating an encryption key with each API server. The said encryption key may be for public key encryption.

So as to securely and reliably communicate executable instructions, the data may comprise an executable instruction.

For efficiency of communication, said received verification may comprise a data identifier.

For efficiency, the method may comprise associating said data identifier with said received data by way of a look up table.

-3Preferably, the method may further comprise confirming via said first route the sending of said data to a central server.

For redundancy, the method may further comprise confirming via said second route the sending of said verification to a central server.

For security, the method may further comprise processing said data following verification.

For redundancy and so as to reduce the effect of compromised or unavailable routes the method may further comprise sending confirmation of processing said data to a third route; wherein said third route is independent of said first and second routes. The method may further comprise said third route confirming the confirmation of said processing to a central server.

Preferably, the method comprises periodically checking for new instructions by way of an info push to at least one of said APIs. The time between periodic checks is between 5 seconds and 5 minutes, preferably between 10 seconds and 2 minutes, preferably between 30 and 60 seconds.

So as to allow for latency within the system, the method may comprise waiting for a specified period of time following requesting said verification from a second route. The specified period of time may be between 5 seconds and 2 minutes, preferably between 15 and 45 seconds.

According to another aspect of the present invention there is provided a computer program product comprising executable instructions adapted to carry out the method as described herein.

According to another aspect of the present invention there is provided an apparatus for validating data, the apparatus comprising: means for receiving data from via a first route; means for requesting a verification of said data from via a second route; and means for determining from said verification of said data whether said data is valid; wherein said first and second routes are independent of one another. In one example, each route comprises an API.

-4According to another aspect of the present invention there is provided a system for validating data, the system comprising: a first subsystem; a plurality of routes, wherein said routes are independent of one another; and a second subsystem; wherein said first subsystem is adapted to: receive data from said second subsystem via a first route of said plurality of routes; and request a verification of said data via a second route of said plurality of routes. In one example, each route comprises an API.

The first subsystem may be adapted to process said data; the data having been transferred in a secure manner.

For security, the system may comprise a third route of said plurality of routes; the first subsystem being adapted to send confirmation of processing said data to said third route.

According to another aspect of the present invention there is provided a system for validating data, the system comprising: a first subsystem; a plurality of routes, wherein said routes are independent of one another; and a second subsystem; wherein said second subsystem is adapted to: receive data from said first subsystem via said plurality of routes; and determine whether said data is valid on the basis of data received from two routes of said plurality of routes. In such a way, data may be validated in a secure, redundant and robust manner. In one example, each route comprises an API.

For secure and redundant communication with a remote system, said second subsystem comprises a central server, and said second subsystem comprises a remote system.

According to another aspect of the present invention there is provided a method of validating data, the method comprising: receiving data via a first route; requesting verification of said data via a second route; wherein said first and second routes are independent of one another; thereby to validate said data received via said first routes. In such a way, data may be validated in a secure, redundant and robust manner.

The invention extends to any novel aspects or features described and/or illustrated herein.

Further features of the invention are characterised by the other independent and dependent claims

-5Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to apparatus aspects, and vice versa.

Furthermore, features implemented in hardware may be implemented in software, and vice versa. Any reference to software and hardware features herein should be construed accordingly.

Any apparatus feature as described herein may also be provided as a method feature, and vice versa. As used herein, means plus function features may be expressed alternatively in terms of their corresponding structure, such as a suitably programmed processor and associated memory.

It should also be appreciated that particular combinations of the various features described and defined in any aspects of the invention can be implemented and/or supplied and/or used independently.

The invention also provides a computer program and a computer program product comprising software code adapted, when executed on a data processing apparatus, to perform any of the methods described herein, including any or all of their component steps.

The invention also provides a computer program and a computer program product comprising software code which, when executed on a data processing apparatus, comprises any of the apparatus features described herein.

The invention also provides a computer program and a computer program product having an operating system which supports a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.

The invention also provides a computer readable medium having stored thereon the computer program as aforesaid.

-6The invention also provides a signal carrying the computer program as aforesaid, and a method of transmitting such a signal.

The invention extends to methods and/or apparatus substantially as herein described with reference to the accompanying drawings.

The invention will now be described by way of example, with references to the accompanying drawings in which:

Figure 1 shows a schematic diagram of the components of a data validation system; Figure 2 shows data being passed around the system; and

Figure 3 shows a flow diagram of a remote system verifying the receipt, and the subsequent processing, of a command.

Detailed description

The requirements for a stable and secure remote processing system include the ability to receive valid instructions and to send valid data to a central server (such as a monitoring system). Examples of remote systems that are required to communicate reliably and securely to a central server include systems on aircraft (such as the in-flight entertainment system), trains, vehicles, satellites, unmanned aerial vehicles, remote military stations, customer systems, and marine vessels.

One method of validating instructions comprises trusting the instructions received from a single Application Program Interface (API), potentially following a single/multi factor authentication process. A subsequent verification of the instruction may be performed by a verification hash where data is reorganised into an agreed format and then hashed with a shared secret. However, such a method may be not be secure in the event of the API become compromised.

In overview, the present system utilises a plurality of Application Program Interface (API) servers as a plurality of routes to provide the ability for cross-checking and validating data sent and received by the remote system. In the present description an API server (or simply API) refers to a method, apparatus or module (either in hardware or software) operable to transfer data between two systems.

-7Figure 1 shows a schematic diagram of the components of the system 100. The system comprises a ‘pool’ of API servers 104, a first subsystem comprising a remote system 102, and a second subsystem comprising a central server 106.

The API servers 104 are separate (physically separated via hardware and/or separated via software), secured independently and communicate with the central server 106 that manages the remote processing system 102. The use of a pool of API servers 104 provides the option of switching between servers in the event that one server becomes unavailable, or is thought to have been compromised (for example by hackers). The API servers 104 may also be physically separate, for example in different countries so as to minimise the risk of several API servers 104 being simultaneously compromised or otherwise unavailable. If it is determined that an API server 104 has been compromised or otherwise unavailable (for example, suffering a system failure) a new API server 104 is selected from the pool. The new API server 104 may be tested for validity and operation before undertaking communication.

In such a way, multiple routes of communication are provided between the central server 106 and the remote system 102, allowing for cross-checking of instructions and layers of redundancy.

In use, communication takes place with three out of the pool of API servers 104 that provide responses to the systems running on the remote system. If an API is unavailable, then another will be chosen from the API pool and that will form part of the three. In one example, the APIs are chosen randomly so as to reduce the possibility of a third party predicting which set of APIs would be chosen.

This data transferred between the central server 106 and the remote system 102 in an encrypted format. For example, the remote system 102 may hold a public key and an additional encryption key is negotiated with each API 104 when the remote system 102 starts up. The negotiation of the encryption key is managed securely using public key encryption.

If the remote system 102 is restarted, the encryption key is lost and must be renegotiated. This is an indication that the remote system 102 has been tampered with and triggers an alert within the central server 106.

-8Data Validation

Figure 2 shows data being passed around the system 100 so as to validate data originating from the remote system 102.

An API call module 108 in the remote system 102 pushes information to API servers 104 5 which in turn push information to an API call module 110 within the central served06.

The information pushed by the API servers 104 may be the same as originating from the remote system 104, or may be processed (for example, encrypting, compressing, and/or converting the data into a format suitable for the central server 106).

The central server 106 then processes the received information S4 (for example, using a processor 112 and associated memory 114), but first determines whether the data has been validated by at least two APIs (S1). This process allows for one API 104 to submit divergent information to the other two (for example, due to external interference or transmission errors) without affecting the processing of the data. The divergent information is discarded without being processed. Following the receipt of information, the system waits for a period (for example, between 5 seconds and 2 minutes, between 15 and 45 seconds, preferably 30 seconds) (S2) so as to provide an opportunity for a second API server 104 to pass information. This allows for differences in transmission times, for example due to the geographic separation between API servers, processing delays, or the repetition of information which may have been corrupted during transmission. If no such confirmatory information is received, the central server 106 alerts the user S5 via output module 116.

In such a way, data can be validated as originating from the remote system. This reduces the possibility of (for example) a hacker gaining access to the system by compromising one of the APIs 104.

Command validation

Figure 3 shows a flow diagram of a remote system verifying the receipt, and the subsequent processing, of a command. This method is similar to the data validation method described above with reference to Figure 2 in that two independent API servers 104 are used to verify a command.

-9In use, each API 104 is issued with a command from the central server 106. The remote system 102 requests information in the form of an info push to a first API 104-1. The first API 104-1 responds with the requested information. The remote system 102 determines at step S1 whether the info push response contains any instructions. If there are no instructions, the process ends at step S2 and repeats. This process may be repeated every 30-60 seconds, although greater or shorter time periods may be appropriate depending on the context. For example, a longer period (for example 2 to 5 minutes) may be appropriate for a communication system with very high latency. Alternatively, a lower period (for example 5 to 10 seconds) may be appropriate where there is expected to be a high frequency of instructions.

If instructions are received, the remote system 102 sends a request to a second API 1042 to verify the command. The second API 104-2 responds with a command verification response. This may take the form the second API 104-2 sending the command again, or alternatively a truncated version of the instruction (for example, a data identifier corresponding to the command). In one example, a unique data identifier is used as the verification. In such an example the code may be interpreted by the remote system 102 by way of a look up table which associates a particular identifier with an instruction, or set of instructions to be executed.

A command identifier or truncated version of the instruction may raise the risk of a modified or corrupted instruction being mistakenly verified, but would require less data transfer between API 104-2 and remote system 102, thereby speeding up the verification process.

The remote system 102 then verifies the instruction received from the first API 104-1 against the verification response received from the second API 104-2 at step S3. If the instruction is not verified, for example, if the instruction received from the first API 104-1 does not match the instruction received from the second API 104-2, the instruction is rejected in step S4 before being executed. An alert is also pushed to the second and third APIs 104-2, 104-3. Sending an alert to two independent APIs 104 means that the alert will still be passed to the central server 106 if the non-verification of the instruction was due to a compromised API 104.

If the instruction is verified, the instruction is executed at step S5. The remote system 102 then sends a command complete message to a third API 104-3. This notifies the central server 102 that the instruction has been executed. The first or second API 104-1,-2 may

- 10be used for notifying the central server 102, but a third API 104-3 is preferable as it is ‘clean’ - having not been involved in the communication prior to this point.

The three APIs 104 independently communicate with the central server 106 as to the status of their respective tasks.

The selection of the first API 104-1 may be may be determined on quality of communication channel; the geographic location of the API 104-1 may act as a proxy for quality of communication channel. The quality of the communication channel is particularly important for the first API 104-1 as this is likely to be the most data-intensive communication and transmission errors would result in the subsequent validation steps blocking the execution of the command. Alternatively, the first API 104-1 may be randomly selected from the API pool.

Alternatives and modifications

Various other modifications will be apparent to those skilled in the art for example the remote system 102 and the central server 106 may be interchanged.

Whilst it is described that the selection and/or ordering of the APIs 104 is performed randomly, load balancing may be applied so as to share load between APIs. In such a way, a load balancer may be utilised to select and/or order the APIs 104 from the pool. The load balancer may take into account the security status of the API and/or system as a whole, the ping time to the API, or the geographic location of the API (which may be related to ping time). Alternatively, the API may be selected by way of a round-robin which ensures the load is spread over multiple APIs. The ordering of the round robin may be random - for example an API is randomly selected from the pool, and then cannot be selected again until all other APIs have been selected once.

In one example, an API which is selected as the ‘first API’ 104-1 for one communication may be selected as the ‘third API’ 104-3 (or not selected at all) for the next communication so as to reduce the proportion of processing performed by one API 104.

It will be understood that the present invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention.

- 11 Reference numerals appearing in the claims are by way of illustration only and shall have no limiting effect on the scope of the claims.

Claims

Claims

1. A method of validating data, the method comprising: receiving data via a first route;

receiving a verification of said data via a second route, wherein said first and second routes are independent of one another; and determining from said verification of said data whether said data is valid.
2. A method according to claim 1 comprising issuing an alert to a central server if it is determined that said data is not valid.
3. A method according to claim 2 further comprising outputting an alert to a user.
4. A method according to claim 2 or 3 wherein said alert is sent to said central server via two independent routes.
5. A method according to claim 4 wherein said two independent routes comprise a third route.
6. A method according to any preceding claim wherein said routes each comprise an Application Program Interface (API).
7. A method according to claim 6 wherein said APIs are physically independent API servers.
8. A method according to claim 6 or 7 wherein said APIs are separated by software.
9. A method according to any of claims 6 to 8 comprising selecting said API servers from a pool of API servers.
10. A method according to any of claims 6 to 9 comprising selecting a replacement API server from a pool of API servers in the event of a compromise or failure of an API server.
11. A method according to claim 9 or 10 wherein said API server is selected by a load balancer.
12. A method according to claim 11 wherein said load balancer selects the API server in dependence on at least one of security status, ping time, round-robin, and geographic location of said API server.

- 1313. A method according to any of claims 9 to 12 comprising testing said selected API server for validity and/or operation.
14. A method according to any of claims 6 to 13 comprising negotiating an encryption key with each API server.
15. A method according to claim 14 wherein said encryption key is for public key encryption.
16. A method according to any preceding claim wherein said data comprises an executable instruction.
17. A method according to any preceding claim wherein said received verification comprises a data identifier.
18. A method according to claim 17 comprising associating said data identifier with said received data by way of a look up table.
19. A method according to any preceding claim further comprising confirming via said first route the sending of said data to a central server.
20. A method according to any preceding claim further comprising confirming via said second route the sending of said verification to a central server.
21. A method according to any preceding claim further comprising processing said data following verification.
22. A method according to claim 21 further comprising sending confirmation of processing said data via a third route; wherein said third route is independent of said first and second routes.
23. A method according to claim 22 further comprising said third route confirming the confirmation of said processing to a central server.
24. A method according to any of claims 16 to 23 when dependent on claim 6 comprising periodically checking for new instructions by way of an info push to at least one of said APIs.
25. A method according to claim 24 wherein said the time between periodic checks is between 5 seconds and 5 minutes.

- 1426. A method according to claim 24 wherein said the time between periodic checks is between 30 and 60 seconds.
27. A method according to any preceding claim comprising waiting for a specified period of time following requesting said verification via said second route.
28. A method according to claim 27 wherein said specified period of time is between 5 seconds and 2 minutes.
29. A method according to claim 27 wherein said specified period of time is between 15 and 45 seconds.
30. A computer program product comprising executable instructions adapted to carry out the method of any preceding claim.
31. An apparatus for validating data, the apparatus comprising: means for receiving data via a first route;

means for requesting a verification of said data via a second route; and means for determining from said verification of said data whether said data is valid;

wherein said first and second routes are independent of one another.
32. An apparatus according to claim 31 wherein said routes each comprise an API.
33. A system for validating data, the system comprising: a first subsystem;

a plurality of routes, wherein said routes are independent of one another; and a second subsystem;

wherein said first subsystem is adapted to:

receive data from said second subsystem via a first route of said plurality of routes; and request a verification of said data via a second route of said plurality of routes.
34. A system according to claim 33 wherein the first subsystem is adapted to process said data.
35. A system according to claim 34 comprising a third route of said plurality of routes; the first subsystem being adapted to send confirmation of processing said data via said third route.

- 1536. A system for validating data, the system comprising: a first subsystem;

a plurality of routes, wherein said routes are independent of one another; and a second subsystem;

wherein said second subsystem is adapted to: receive data from said first subsystem via said plurality of routes ; and determine whether said data is valid on the basis of data received via two routes of said plurality of routes.
37. A system according to claim any of claims 33 to 36 wherein said second subsystem comprises a central server, and said second subsystem comprises a remote system.
38. A system according to any of claims 33 to 37 wherein said routes each comprise an API.
39. A method of validating data, the method comprising: receiving data via a first route;

requesting verification of said data via a second route;

wherein said first and second routes are independent of one another;

thereby to validate said data received via said first route.
40. A method substantially as herein described and illustrated with reference to the accompanying figures.
41. An apparatus substantially as herein described and illustrated with reference to the accompanying figures.
42. A system substantially as herein described and as illustrated with reference to the accompanying figures.
43. A computer program product substantially as herein described and illustrated with reference to the accompanying figures.

Intellectual

Property

Office

Application No: Claims searched:

GB1611456.3

1-43