...
To be sure that every OCPI message is not modified without our permission during its transit, the Open Charging Network requires that every OCPI message is signed by its sender*. * This is achieved by implementing the OCN-Signature to in your OCPI 2.2 interface. Any node of the Open Charging Network production environment requires application of the OCN-Signature, otherwise your OCPI messages will not get transmitted.
*In fact, OCN-Node Operators can optionally disable the requirement for signed messages. However, we strongly advice advise not to run OCN-Nodes on the Production Environment without message signing enabled.
...
Taking a cue from the blockchain community, we have developed a message signing and verifying system for the Open Charging Network. Under the hood it uses the Elliptic Curve Digital Signature Algorithm (ECDSA) as implemented by Ethereum. The signature itself is contained within a JSON object which is base64 encoded and appended to the holds a JSON Object containing all the necessary data for the recipient to verify the data it is receiving. Not only do requests need to be signed, but responses too.
For requests, the signature is appended to the outgoing OCPI 2.2 headers, under the label “OCN-Signature”, as shown below:
| Code Block |
|---|
Authorization: Token 0ea32164-515f-418b-8bef-39f3817ea090
X-Request-ID: 71d62c5b-5017-493e-be00-3f5ad4e34fff
X-Correlation-ID: 9881b6f7-63aa-40d2-b9c2-d6daa69c11fb
OCPI-From-Country-Code: CH
OCPI-From-Party-Id: MSP
OCPI-To-Country-Code: CH
OCPI-To-Party-Id: CPO
OCN-Signature: eyJmaWVsZHMiOlsiJFsnaGVhZGVycyddWyd4L (truncated)... |
For responses, the signature is appended to the outgoing OCPI 2.2 JSON response body:
| Code Block | ||
|---|---|---|
| ||
{ "status_code": 1000, "data": { "result": "ACCEPTED" }, "timestamp": "2020-03-02T12:48:33.005Z", "ocn_signature": "eyJmaWVsZHMiOlsiJFsnaGVhZGVycyddWyd4L (truncated)..." } |
The idea is that the recipient can use this signature to verify that the message has been signed correctly and has not been modified by an unauthorized party. What do we mean by unauthorized? For the OCN to function properly, there are cases where an intermediary (i.e. an OCN node) needs to modify the request/response. Such an example would be the response_url in the JSON body of requests made to the receiver interface of the OCPI commands module. As the recipient does not have access to the response_url defined by the sender, the OCN Node must modify the value. In an OCN signature, this is known as “stashing”. The signature object contains the history of rewrites, with the previous signature being stashed by the party modifying the requestdata. When a recipient then verifies a signature, the rewrites are also verified.
...
The signature itself contains everything needed to verify the most-recent version of the requestsent data, i.e. by the sender or OCN node depending on whether any values needed to be modified. Provided is a list of jsonpath fields which can be used to recreate the message as signed by the sender, with the original order of values preserved. The values are hashed using keccak-256, as implemented by Ethereum. The resultant hash is actually the message which is signed. The RSV is the signature, produced by ECDSA using an Ethereum wallet’s private key. The signatory refers to the address of the wallet that was used to sign the message.
...