GB2551808A - Data validation - Google Patents

Data validation Download PDF

Info

Publication number
GB2551808A
GB2551808A GB1611456.3A GB201611456A GB2551808A GB 2551808 A GB2551808 A GB 2551808A GB 201611456 A GB201611456 A GB 201611456A GB 2551808 A GB2551808 A GB 2551808A
Authority
GB
United Kingdom
Prior art keywords
data
route
routes
api
subsystem
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
GB1611456.3A
Other versions
GB201611456D0 (en
Inventor
James Cowan Alexander
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Razorsecure Ltd
Original Assignee
Razorsecure Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Razorsecure Ltd filed Critical Razorsecure Ltd
Priority to GB1611456.3A priority Critical patent/GB2551808A/en
Publication of GB201611456D0 publication Critical patent/GB201611456D0/en
Publication of GB2551808A publication Critical patent/GB2551808A/en
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/629Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/18Network architectures or network communication protocols for network security using different networks or paths for security, e.g. using out of band channels

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 (40)

  1. 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. 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. 3. A method according to claim 2 further comprising outputting an alert to a user.
  4. 4. A method according to claim 2 or 3 wherein said alert is sent to said central server via two independent routes.
  5. 5. A method according to claim 4 wherein said two independent routes comprise a third route.
  6. 6. A method according to any preceding claim wherein said routes each comprise an Application Program Interface (API).
  7. 7. A method according to claim 6 wherein said APIs are physically independent API servers.
  8. 8. A method according to claim 6 or 7 wherein said APIs are separated by software.
  9. 9. A method according to any of claims 6 to 8 comprising selecting said API servers from a pool of API servers.
  10. 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. 11. A method according to claim 9 or 10 wherein said API server is selected by a load balancer.
  12. 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.
  13. 14. A method according to any of claims 6 to 13 comprising negotiating an encryption key with each API server.
  14. 15. A method according to claim 14 wherein said encryption key is for public key encryption.
  15. 16. A method according to any preceding claim wherein said data comprises an executable instruction.
  16. 17. A method according to any preceding claim wherein said received verification comprises a data identifier.
  17. 18. A method according to claim 17 comprising associating said data identifier with said received data by way of a look up table.
  18. 19. A method according to any preceding claim further comprising confirming via said first route the sending of said data to a central server.
  19. 20. A method according to any preceding claim further comprising confirming via said second route the sending of said verification to a central server.
  20. 21. A method according to any preceding claim further comprising processing said data following verification.
  21. 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.
  22. 23. A method according to claim 22 further comprising said third route confirming the confirmation of said processing to a central server.
  23. 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.
  24. 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.
  25. 27. A method according to any preceding claim comprising waiting for a specified period of time following requesting said verification via said second route.
  26. 28. A method according to claim 27 wherein said specified period of time is between 5 seconds and 2 minutes.
  27. 29. A method according to claim 27 wherein said specified period of time is between 15 and 45 seconds.
  28. 30. A computer program product comprising executable instructions adapted to carry out the method of any preceding claim.
  29. 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.
  30. 32. An apparatus according to claim 31 wherein said routes each comprise an API.
  31. 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.
  32. 34. A system according to claim 33 wherein the first subsystem is adapted to process said data.
  33. 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.
  34. 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.
  35. 38. A system according to any of claims 33 to 37 wherein said routes each comprise an API.
  36. 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.
  37. 40. A method substantially as herein described and illustrated with reference to the accompanying figures.
  38. 41. An apparatus substantially as herein described and illustrated with reference to the accompanying figures.
  39. 42. A system substantially as herein described and as illustrated with reference to the accompanying figures.
  40. 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
GB1611456.3A 2016-06-30 2016-06-30 Data validation Pending GB2551808A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
GB1611456.3A GB2551808A (en) 2016-06-30 2016-06-30 Data validation

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB1611456.3A GB2551808A (en) 2016-06-30 2016-06-30 Data validation

Publications (2)

Publication Number Publication Date
GB201611456D0 GB201611456D0 (en) 2016-08-17
GB2551808A true GB2551808A (en) 2018-01-03

Family

ID=56891434

Family Applications (1)

Application Number Title Priority Date Filing Date
GB1611456.3A Pending GB2551808A (en) 2016-06-30 2016-06-30 Data validation

Country Status (1)

Country Link
GB (1) GB2551808A (en)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002014974A2 (en) * 2000-08-14 2002-02-21 Comsense Technologies, Ltd. Multi-server authentication
GB2419785A (en) * 2004-10-27 2006-05-03 Roke Manor Research Ensuring the integrity of data by transmitting over at least two separate paths and comparing each reception to determine reliability
US20080243990A1 (en) * 2007-03-27 2008-10-02 International Business Machines Corporation Methods, systems, and computer program products for continuous availability of non-persistence messages in a distributed platform
US20120123806A1 (en) * 2009-12-31 2012-05-17 Schumann Jr Douglas D Systems and methods for providing a safety score associated with a user location
US20140045568A1 (en) * 2012-08-08 2014-02-13 Scientific Games International, Inc. System and Method for Lottery Ticket Verification by Players
US20140307628A1 (en) * 2011-09-29 2014-10-16 Continental Teve AG & Co., oHG Method and System for the Distributed Transmission of a Communication Flow and Use of the System
US20160180307A1 (en) * 2010-04-09 2016-06-23 Paypal, Inc. Mobile phone atm processing methods and systems

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002014974A2 (en) * 2000-08-14 2002-02-21 Comsense Technologies, Ltd. Multi-server authentication
GB2419785A (en) * 2004-10-27 2006-05-03 Roke Manor Research Ensuring the integrity of data by transmitting over at least two separate paths and comparing each reception to determine reliability
US20080243990A1 (en) * 2007-03-27 2008-10-02 International Business Machines Corporation Methods, systems, and computer program products for continuous availability of non-persistence messages in a distributed platform
US20120123806A1 (en) * 2009-12-31 2012-05-17 Schumann Jr Douglas D Systems and methods for providing a safety score associated with a user location
US20160180307A1 (en) * 2010-04-09 2016-06-23 Paypal, Inc. Mobile phone atm processing methods and systems
US20140307628A1 (en) * 2011-09-29 2014-10-16 Continental Teve AG & Co., oHG Method and System for the Distributed Transmission of a Communication Flow and Use of the System
US20140045568A1 (en) * 2012-08-08 2014-02-13 Scientific Games International, Inc. System and Method for Lottery Ticket Verification by Players

Also Published As

Publication number Publication date
GB201611456D0 (en) 2016-08-17

Similar Documents

Publication Publication Date Title
US9864608B2 (en) Client authentication during network boot
US10581907B2 (en) Systems and methods for network access control
US9825927B2 (en) Systems and methods for securing data using multi-factor or keyed dispersal
US20160379005A1 (en) Systems and methods for securing data in motion
US9465952B2 (en) Systems and methods for secure multi-tenant data storage
US20200274711A1 (en) Secure file sharing method and system
US20160337326A1 (en) Systems and methods for managing cryptographic keys
US10235503B2 (en) In-vehicle content delivery system operable in autonomous mode and non-autonomous mode
US20190026479A1 (en) Secure data parser method and system
US20170286669A1 (en) Systems and methods for securing virtual machine computing environments
US9906493B1 (en) Method and system for verifying the integrity of computing devices
US10257230B2 (en) System and method for encryption key management, federation and distribution
JP5650348B2 (en) System and method for securing data in motion
KR20180002803A (en) Automatic Identification of Invalid Participants in the Security Synchronization System
US9009848B2 (en) Secure data parser method and system
US20160132401A1 (en) Systems and methods for secure remote storage
US20160196440A1 (en) Systems and methods for secure data sharing
US20160103770A1 (en) Tape backup method
US8601498B2 (en) Accelerator system for use with secure data storage
US8732462B2 (en) Methods and apparatus for secure data sharing
US8654971B2 (en) Systems and methods for securing data in the cloud
US8644502B2 (en) Secure data parser method and system
JP6556840B2 (en) Methods, storage subsystems, cloud storage systems, data processing programs, and computer program products (automated management of sensitive data in a cloud environment) for storing data in a shared networked environment
US9106617B2 (en) Methods, systems and computer program products for authenticating computer processing devices and transferring both encrypted and unencrypted data therebetween
US9021264B2 (en) Method and system for cloud based storage