Verification of process integrity

Abstract

A system implements a secure transaction of data between a server and a remote device. The remote device comprises: processing means adapted to process input data according to a security process; data storage means adapted to store verification information derived from the input data according to an encryption algorithm; and communication means for communicating the input data which has been processed by the security process to the server. The server is adapted to transmit a verification request to the remote device, and to verify the integrity of the security process based on verification information received from the communication means of the remote device in response to the verification request.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a
Bi←i|Ci Hi,  (2)
where HASH is a cryptographically secure one-way hash function such as defined in the state-of-the-art (for example, a suitable candidate is the standard SHA-256, soon to be replaced in the coming years by NIST after completion of their open competition for new hash function standard).

Due to the one-way nature of the hash function, it is not possible to infer from Bi any information relative to Gi, hence preserving the privacy of the driver. In step 540, the binding data is then sent to the ATOP secure controller 46 for signing (step 550) according to equation 3:
Si←EC-DSA-SIGN{SK_ATOP}(Bi)  (3)

In this case, the well-known signature algorithm DSA is used along with an elliptic curve private key SK_ATOP. Any other similar or suitable algorithm can be used.

As a last step, step 560, the binding information, which includes the package identifier i, the computed cost Ci, and GPS data hash, and the signature Si is sent to the remote Road-Pricing server 12.

On reception (step 570), the server 12 verifies the integrity of the transmitted data by verifying the validity of the signature, using ATOP public key PKATOP according to equation 4:
Correct/Incorrect←EC-DSA-VERIFY{PKATOP}(Si, Bi)  (4)

On a random basis, the server 12 will also transmit a request for cost to the ATOP baseband controller 44 to prove the correctness of the computed cost according to equation 5:
No Request/Enforcement Request←RAN-DOM( )>threshold  (5),
where RANDOM( ) is a secure random generator generating a value between 0 and 1, and threshold is a pre-defined threshold value that is defined by the Road-Pricing Operator after taking into account various factors including the wanted frequency of controls, the cost of transmission, the impact on privacy, the extra workload at server side, for example.

There are three possible outcomes:

• 1) the signature integrity is incorrect—This is notified to the transmitting ATOP, which can then, for instance request that the information be resent to the server. If the signature fails a second time, a fraud manager can be notified for further investigation.
• 2) The signature is correct, and no enforcement request triggered—In this case, the server 12 replies to the ATOP with an acknowledgement message, and execution continues normally to the billing process (step 580).
• 3) The signature is correct, and an enforcement request is triggered—In this case, the server 12 replies to the ATOP baseband controller 44 by transmitting a request for bound GPS data corresponding to the package i (step 590).

The ATOP baseband controller 44 looks up the requested GPS data package in its database 50 and transmits the requested information back to the server 12 (step 600). Prior to step 600, the ATOP baseband controller 44 can notify the user (i.e. the driver of a vehicle carrying the OBU of this embodiment) that an enforcement request is on-going (step 610), and that supplementary information must be transmitted to comply with the request. This can be a simple notification message on an alphanumeric display, giving for instance the date and time of the trip to transmit, or a graphical display on a map of the actual trip information that must be transmitted. It may be preferable to arrange that the driver must press on a button to give his consent before information can be transmitted back to the server in response to the enforcement request.

On reception of the bound data, the server 12 will hash the GPS data Gi and compare the result with the transmitted hash contained in the binding data that has been transmitted previously according to equation 6:
Correct/Incorrect←Hi=^?HASH(Gi)  (6)

If this verification process in step 620 is passed, the RP Server will then compute the cost corresponding to the transmitted trip data Gi, and compare the result with the cost Ci previously transmitted, as detailed in equation 7:
Correct/Incorrect←Ci=^?COMPUTE-COST(Gi)  (7)

If this verification process is passed, the method proceeds normally to the billing process of step 580. On the other hand, if the verification fails in either of the comparisons made above according to equations 6 and 7, the server 12 notifies the ATOP in step 640, which can take appropriate action (for example, retry the data transmission, display a message to the driver, etc.). On successive failure, the server 12 notifies a fraud manager for further investigation.

It is noted that the embodiment described above with reference to FIG. 5 only includes verification of processes performed in the external controller 48. It does not guarantee the integrity of data submitted to the external controller (for example, GPS data). It is assumed that the integrity of such input data is protected by other security mechanisms independent of the current invention.

The invention has been described in connection with single frequency GPS, but other GNSS systems (GLONASS, Galileo etc) would be similar. Indeed the techniques could also be applied to multiple frequency systems, with appropriate means of capturing the IF data from each carrier.

Various additional features and modifications will be apparent to those skilled in the art.

Claims

1. A system comprising a server and a remote device and in a system comprising a server, the remote device configured to implement a secure transaction of data between with the server and remote device, wherein the remote device comprises:

a processing device configured to process input data according to a security process;

a data storage device configured to store verification information derived from the input data;

a communication device configured to communicate the processed input data which has been processed by the security process to the server, wherein the server is configured to transmit receive a verification request to from the remote device server, verify integrity of the security process based on and communicate the stored verification information received from the data storage device in response to the verification request for the server to verify integrity of the security process; and

a secure processor, wherein the verification information is derived from the input data according to an encryption algorithm implemented by the secure processor,

wherein the remote device is configured to communicate verification information to the server only in response to receiving a verification request from the server.

2. The system remote device according to claim 1, wherein the remote device is a vehicle mounted unit comprising a global navigation system receiver configured to implement a position tracking function, and wherein the communication device comprises a mobile telephony receiver.

3. The system remote device according to claim 2, wherein the input data is derived from data output from the global navigation system receiver.

4. The system remote device according to claim 1, wherein the security process is configured to process input data such that the processed data does not disclose information related to the content of the input data.

5. The system remote device according to claim 4, wherein the security process is a cryptographically secure one-way hash function.

6. The system remote device according to claim 1, wherein the server is configured to process verification information received from the remote device according to a supplementary security process so as to verify the integrity of the security process undertaken by the remote device.

7. The system remote device of claim 1, further comprising:

a database, local to the remote device, that is configured to store the verification information.

8. A method of implementing at a remote device a secure transaction of data between with a server and a remote device, the method comprising:

processing input data, in the remote device, according to a security process;

storing verification information derived from the input data;

communicating the processed input data to the server;

transmitting receiving a verification request from the server to the remote device;

communicating, from the remote device, the stored verification information to the server in response to the verification request; verifying, at for the server, to verify integrity of the security process based on the verification information communicated to the server; and

deriving the verification information from the input data according to an encryption algorithm implemented by a secure processor,

wherein the remote device is configured to communicate verification information to the server only in response to receiving a verification request from the server.

9. The method as claimed in claim 8, wherein the remote device is a vehicle mounted unit comprising a global navigation system receiver configured to implement a position tracking function, and wherein the step of communicating is implemented using a mobile telephony receiver.

10. The method as claimed in claim 9, further comprising:

deriving the input data from data output from the global navigation system receiver.

11. The method as claimed in claim 8, wherein the step of processing input data comprises:

processing input data such that the processed data does not disclose information related to the content of the input data.

12. The method as claimed in claim 11, wherein the step of processing input data comprises:

processing input data using a cryptographically secure one-way hash function.

13. The method as claimed in claim 8, wherein the step of verifying comprises: processing integrity of the verification information received from communicated by the remote device is verified according to a supplementary security process.

14. The method of claim 8, further comprising:

storing the verification information in a database which is local to the remote device.

15. The method of claim 8, further comprising:

notifying a user that the remote device has received an enforcement a verification request requiring data to be sent to the server.

16. The method of claim 8, wherein further comprising verifying, at the server, further comprises by:

verifying a signature of binding data; and

subsequently verifying the binding data.

17. The method of claim 8, further comprising:

communicating, to the server, a package identifier, computed cost, GPS data hash, and a signature.

18. A non-transitory medium readable by a machine, the non-transitory medium comprising:

instructions for processing input data, in a remote device, according to a security process;

instructions for storing verification information derived from the input data;

instructions for communicating the processed input data to the server;

instructions for transmitting processing a verification request from the server to the remote device;

instructions for communicating the stored verification information from the remote device to the server in response to the verification request;

instructions for verifying, at the server, for the server to verify integrity of the security process based on the verification information communicated to the server; and

instructions for deriving the verification information from the input data according to an encryption algorithm implemented by a secure processor,

wherein the remote device is configured to communicate verification information to the server only in response to receiving a verification request from the server.