What type of Encryption mechanism are used with OCEN APIs?

Mahesh · October 14, 2020, 9:34am

Communication between LSP and lender
All entities are connected over 2-way SSL ( with mutual authentication ).
All communication between the LSP and Lender should be digitally signed as per the JSON Web Signature Specification. The following illustration gives a brief overview of the signing mechanism.
How to generate a public key:
This is a self generated certificate.
openssl genrsa -out privatekey.txt 2048
openssl rsa -in privatekey.txt -pubout -out publickey.txt

Sample Public Key

The JSON Web Signature (RFC7515) standard describes the process of creation and validation of a data structure representing a signed payload. Let’s take an example for the TriggerLoanAcceptanceRequest API. The JSON request object will look like the following:
{
“metadata”: {
“version”: “1.0”,
“timestamp”: “2018-12-06T11:39:57.153Z”,
“traceId”: “e8cc6822bd4bbb4eb1b9e1b4996fbff8acb”,
“orgId”: “LSP123”
},
“requestId”: “e8cc6822bd4bbb4eb1b9e1b4996fbff8acb”,
“loanApplicationIds”: [
“e8cc6822bd4bbb4eb1b9e1b4996fbff8acb”
],
“credBlock”: {
“type”: “OTP”,
“data”: {
“appToken”: “0aBCD7DMr7s”
}
}
}

Before we can sign this, we need to stringify the payload, utf8 encode and then base64 encode this object to obtain the payload. The result of the base64url encoding of the above transaction is:
eyJtZXRhZGF0YSI6eyJ2ZXJzaW9uIjoiMS4wIiwidGltZXN0YW1wIjoiMjAxOC0xMi0wNlQxMTozOTo1Ny4xNTNaIiwidHJhY2VJZCI6ImU4Y2M2ODIyYmQ0YmJiNGViMWI5ZTFiNDk5NmZiZmY4YWNiIiwib3JnSWQiOiJMU1AxMjMifSwicmVxdWVzdElkIjoiZThjYzY4MjJiZDRiYmI0ZWIxYjllMWI0OTk2ZmJmZjhhY2IiLCJsb2FuQXBwbGljYXRpb25JZHMiOlsiZThjYzY4MjJiZDRiYmI0ZWIxYjllMWI0OTk2ZmJmZjhhY2IiXSwiY3JlZEJsb2NrIjp7InR5cGUiOiJPVFAiLCJkYXRhIjp7ImFwcFRva2VuIjoiMGFCQ0Q3RE1yN3MifX19
Additional parameters are associated with each payload. One of those is the required “alg” parameter, which indicates what algorithm needs to be used to generate a signature. This is a mandatory field. Another parameter we will be using is “kid”. “Kid” is a hint indicating which key was used to sign the JWS.

All the above-mentioned parameters are included in the final JWS. These have to be sent as protected headers. Assume we want to sign our payload using a key as we generated in the previous section. Our header JSON would look like this:
{
“kid”: “cb59cce2-7581-414d-bff7-6ecf132dbef1”,
“alg”: “RS512”
}

and base64url encoded this would be:
eyJraWQiOiJjYjU5Y2NlMi03NTgxLTQxNGQtYmZmNy02ZWNmMTMyZGJlZjEiLCJhbGciOiJSUzUxMiJ9

We will be using the RS512 algorithm for our use case. RS512 is an abbreviation for RSASSA-PKCS1-v1_5 using SHA-512.

The base64url encoded payload and protected header are concatenated with a ‘.’ to form raw data, which is fed to the signature algorithm to produce the final signature. Finally, all of this output will be structured using the Flattened JWS JSON Serialization Syntax.
What will a Lender and LSP get in every request/response/ack?

curl -X POST -H ‘Content-Type: application/json’ -d
‘{
“payload” : “eyJtZXRhZGF0YSI6eyJ2ZXJzaW9uIjoiMS4wIiwidGltZXN0YW1wIjoiMjAxOC0xMi0wNlQxMTozOTo1Ny4xNTNaIiwidHJhY2VJZCI6ImU4Y2M2ODIyYmQ0YmJiNGViMWI5ZTFiNDk5NmZiZmY4YWNiIiwib3JnSWQiOiJMU1AxMjMifSwicmVxdWVzdElkIjoiZThjYzY4MjJiZDRiYmI0ZWIxYjllMWI0OTk2ZmJmZjhhY2IiLCJsb2FuQXBwbGljYXRpb25JZHMiOlsiZThjYzY4MjJiZDRiYmI0ZWIxYjllMWI0OTk2ZmJmZjhhY2IiXSwiY3JlZEJsb2NrIjp7InR5cGUiOiJPVFAiLCJkYXRhIjp7ImFwcFRva2VuIjoiMGFCQ0Q3RE1yN3MifX19”,
“header” : “eyJraWQiOiJjYjU5Y2NlMi03NTgxLTQxNGQtYmZmNy02ZWNmMTMyZGJlZjEiLCJhbGciOiJSUzUxMiJ9”,
“signature” : “c1NybGVra0BYJ1n5SAV5XckiQyen5rxmJKUhcvqjnDo3ZZaLN1kb3XQefu2iphorwcOLA4cPX_GVGdMbCOvwOOYnGomNeZ83gpdPUcnioa42Ywjk_-jKg8RqBWTKyIROAWjnACd2rufJxjwI7maO33T7btwUjsTRymAqNt6Bne36Nk_1ZAEKbeLXANzldZAsHGav3nA0E88TAQ_HWf1iQREHxS2Q2ASvfGvtSmORmwsPHAng_8NUEDKvfqwsc5R0lNbMwagsEkILp9gHQbuYHHXv1IcHOKlCNP0H6Z-PmBQc295mw_u8J7shx_7P7RefOib1ISrKkbdpD4aChzoZew”
}’