Signature Validity

[payneBrandon]

Currently the ODE calls out to the HSM without passing any sigValidityOverride parameter, thereby using the default 4 hours. This is no longer working as TIMs live for significantly longer than this timespan and the new OBUs are taking this lifetime into account. To combat this issue the following changes to the Asn1EncoderDataRouter module should be made:

Include sigValidityOverride When sending a TIM for signature, the ODE should include the sigValidityOverride parameter. This parameter should match the max dataFrame.durationTime from the given TIM. This will ensure that any dataFrame within the TIM will have adequate signature duration.

Record Failed/Truncated Signature Requests Despite the change above, we will run into the case where the requested duration of a TIM exceeds the remaining time before the certificate expires. The ODE should report these incidents by using a new Kafka topic. If a TIM sent for signing comes back with a signature whose duration is shorter than the TIM’s duration, then the original JSON for that TIM as well as the signed duration should be published to a new Kafka topic. The rest of the ODE functionality should proceed as usual – i.e. the signed TIM should continue to be processed and published to the appropriate Kafka topics.

[TonyEnglish]

TMCA_UsersGuide_v1.2.pdf Documentation about the sigValidityOverride (unsigned integer valid 0 to 2^32-1 in units of milliseconds.

[payneBrandon]

For the formatting of the message in the new Kafka topic, it should include the full TIM JSON as well as the true signatory expiration date. An example can be seen in the attached file. Note that I grabbed the "tim" portion of the example from the topic.OdeTimJson Kafka topic. expiration_time_TIM.txt

[jtbaird]

We have submitted the code for the first part of issue #370 and to send the max duration time down the pipe to get signed.

Without the second part of the task, it will be difficult to determine if that signature is going through properly or not. There is no change in the output for us to view without decoding the signature. We need a way to get an expiration time from the TMCA response or a way to parse the encrypted signature to extract the expiration time.

ISS have agreed to modify their api to return the decoded message that will have the expiration time in it. The api will be updated to have two additional attributes, “message-decoded” and “message-expiry”.

[TonyEnglish]

Have tested the updated codebase with a node.js sample app (email Tony for copy if needed) that shows the new result for the JSON: { "message-signed": "A4EAQAOAgeYwMDFmNzAyMDEwMDAwMDAwMDAwMWUwMGFkM2IwODI3MjliODk4MWVjNTk3MTcwZTI5NGI5MDMwMjJmYzQzNWY1ZTJkMDMwNDA3ZTUzNzEzMDNkOGIyZTJlMWM1Mjk3MDBiNzY4MTgxMDAyMThiMmUzMjExMjZlMjY1OGE5OGIyZTJmNDNhNmUyNjFjMTM4YjJlMmNmYzI2ZTI1ZTliODE0MTQ2MmNiOGE1NDU5Yjg5NjUxMjYyY2I4OTQxNjliODk1NTcyNjJjYjg4NGNhOWI4OTQ5ZjgxMGIyMDA4NjA4ODQ0MDA2ZWABgwAB2+BpAG4XAAHb6MrE1heBAQEAAwGAFjGvtfwlXQ9QgghBG007uUw++15vWwADHy0yQoQAqYMBAYADSAEBAAGDgYK1MeCn4A9+MdG4oVYwvN1SmdodhCUwPff4VcMFSeq+boCCb1bh62r7SN6kpLmiFF2CzgJCqYpVBd4gr9llyYQLLiohsBdQ6kO/76knioUB/o1YQXVgX0N8ZNRUNIK31lzhOw==", "message-decoded": { "protocolVersion": 3, "content": { "signedData": { "hashId": "sha256", "tbsData": { "payload": { "data": { "protocolVersion": 3, "content": { "unsecuredData": "3030316637303230313030303030303030303031653030616433623038323732396238393831656335393731373065323934623930333032326663343335663565326430333034303765353337313330336438623265326531633532393730306237363831383130303231386232653332313132366532363538613938623265326634336136653236316331333862326532636663323665323565396238313431343632636238613534353962383936353132363263623839343136396238393535373236326362383834636139623839343966383130623230303836303838343430303665" } } }, "headerInfo": { "psid": 131, "generationTime": 523231857503767, "expiryTime": 523267857503767 } }, "signer": { "certificate": [ { "version": 3, "type": "implicit", "issuer": { "sha256AndDigest": "1631AFB5FC255D0F" }, "toBeSigned": { "id": { "binaryId": "411B4D3BB94C3EFB" }, "cracaId": "5E6F5B", "crlSeries": 3, "validityPeriod": { "start": 523055682, "duration": { "hours": 169 } }, "region": { "identifiedRegion": [ { "countryOnly": 840 } ] }, "appPermissions": [ { "psid": 131 } ], "verifyKeyIndicator": { "reconstructionValue": { "compressed-y-0": "B531E0A7E00F7E31D1B8A15630BCDD5299DA1D8425303DF7F855C30549EABE6E" } } } } ] }, "signature": { "ecdsaNistP256Signature": { "r": { "compressed-y-0": "6F56E1EB6AFB48DEA4A4B9A2145D82CE0242A98A5505DE20AFD965C9840B2E2A" }, "s": "21B01750EA43BFEFA9278A8501FE8D584175605F437C64D4543482B7D65CE13B" } } } } }, "message-expiry": 1596183053 }

and this is for a ['sigValidityOverride'] = 36000000; //so 10 hours in milliseconds

giving a result of (using the message-expiry):

Certificate Expiration Time -> 2020-07-31T08:10:53.000Z Current Time -> 2020-07-30T22:10:52.297Z Hours to certificate expiration -> 10.000195277777777

with code of: jsoncontent = JSON.parse(body); var cert_expiration = new Date(jsoncontent["message-expiry"]*1000); var current_time = new Date(); var hours_to_expiration = Math.abs(cert_expiration-current_time)/3600000; console.log("Certificate Expiration Time -> ", cert_expiration); console.log("Current Time -> ", current_time); console.log("Hours to certificate expiration -> ", hours_to_expiration);

[jtbaird]

Closed as part of release 1.2.0