Parsing Secured Packet v3 with Certificate in signer container

[Rom-1T]

Hi everyone,

I'm working on implementing Security v3 using Vanetza. I'm encountering an issue when attempting to use a certificate within the signer container. I'm receiving the error: "packet because of Parse_Secured_Header (2)".

I initially suspected the issue might be related to the ASN.1 library version. However, upgrading to version 2.2.1 using the pull request https://github.com/riebl/vanetza/pull/223/commits did not resolve the problem.

Has anyone else tried to decode a Secured Packet v3 that includes a certificate inside the signer container? Any insights or experiences you can share would be greatly appreciated.

[valt2017]

Is your modified code available somewhere? Otherwise, I'm not sure if anyone will be able to help.

[riebl]

Alternatively, a dump of the packet for which the parsing fails may be helpful.

[Rom-1T]

I recently joined a working team that has been using Vanetza for quite some time now. The version they were using was quite old, so I updated it to a newer version. I don't think our version has been modified for the lower layers; we mainly focus on the application layer. My question is more about whether my update is missing any important aspects (such as recompiling ASN1 files) or if a particular feature is unstable. Anyway, here is the dump : 'ffffffffffff3efcfc9bbacb89471200f20203810040038081962040000000620a00008e00003c440ad0a27720c2916f88dc1dfe11710217aea4800000001dfdf47c02179769138800000000000007d2000002011e57c022c100001453000112922db53704a48b6d9e153a2dd7c6d616969000000000dbba1fa8c00010610311ffff7ffff1ce03fe8d0279639c07fd0a049ac73800087fffdffffc7387fd5dfc91c7387fb2dfa72c7387f659f8a8c738500125000244581bae9cfc1dfe11710217aea40078810101800300800ea1df3d94fa8f68108300000000002604f946832760010880012481040301800080012581050401ffb62080018981030201e080018a81030201c080018b81070601b2a8a67ee08002027d810201018002406b810302018000018d808082718b53c49a32ed6c8e9f76e8472826ad1b601fd2d86375031f8771b19e35b0c080804df422e4438a595886da6e9d212a558904030da545d99d3a7f44ed23808baf3ae449eaed9f405f211e942ae333a570b8418c0424380b02d0f8b42467cfb6d11b80807ea88c8fc5dbcd199ad7661b28bd996dca10085b8a4a11b31ec5413fe545effeb470f5dd988dc780a1a08d8334ea3f0290c3a064d5c31f4230d232678f530fb1000000006a6416ed9bd0ef32e1908842a746eee400000000341ae88e00000000'

[valt2017]

The DENM message seems to be OK (it can be decoded in Wireshark). Maybe it's a stupid idea, but can you please remove the generationLocation element from the headerInfo and try it again?

[valt2017]

I suspect Elevation.c and ElevInt.c files in vanetza asn1 directories. Elevation should be 2bytes long (-4096 .. 61439) in asn oer constraints. When I update the files manually, it seems to be working. But someone else with the proper knowledge should confirm or deny this.

[Rom-1T]

I tried to remove the generationLocation and I still got nothing. I deeply think the problem lies into the difference between my branch and the vanetza master branch. I will go deeper in the problem thank you for your help tho.

Edit 2: I've tested it with a fresh vanetza install (last commit) and socketap. I have still trouble and as @valt2017 said it is because of the 'generationLocation'. I've generated test packets. Here is the one I can decode (without generationLocation) : ''ffffffffffff0000000110008947120015010381004003805820500280003405001400000000000000280015491d133cc0013ee8a0800000000000000007d1000002020000009a75c04006b49d200d693a40023023020830d41458000000000002908a8333ff81fffa003fe0141980000040012400000000000000008101018003008080b063a068107b88008300000000000000059182003c81832b6a5512a84c92d0d7d742511b02674da2c4abcfae33e9bf4cf58b3fb697e43680806cd317b74641cfd49585647b9ac115c3e00b9b2bc6a4e380fb919fd7f7aeca38e4a44ff4cf0a7c595aa4eb4f4ddf9f396637cf9cb0710ee7f98af7a9a31b397a8080fc8cdcd0603025357acb96445af34e537993ceb9b1d512d0b95fea4735d38fc6c44a6af7db62a88063416261853356f3190b9e53d2a65b966de9ff54fa41d8a9".

Here is the one I can not decode : "ffffffffffff0000000110008947120015010381004003805820500280003405001400000000000000280015491d133cc0013ee8a0800000000000000007d1000002020000009a58504006b49d200d693a40023023020830d41458000000000002908a8333ff81fffa003fe014198000005001240000000000000000000186a000004e2000648101018003008080b063a068107b88008300000000000000059182003c81832b6a5512a84c92d0d7d742511b02674da2c4abcfae33e9bf4cf58b3fb697e43680806cd317b74641cfd49585647b9ac115c3e00b9b2bc6a4e380fb919fd7f7aeca38e4a44ff4cf0a7c595aa4eb4f4ddf9f396637cf9cb0710ee7f98af7a9a31b397a8080451d43fc604f3c8169eaab778d177dd3f9f2987474d43757b92cb654e6aee75229b0e3c7001d68ce704af0c34273ce65769b919ab19265aa711c8e82f9d16bdf"

How did you fix it @valt2017 ?

[valt2017]

My version of security 1.3.1 sources and probably also version of ASN files is different from the mainstream. I changed the line in Elevation.c file in /asn/its directory because Elevation oer encoding used 4 Bytes instead of 2 Bytes in my case (constraints were OK).
static asn_oer_constraints_t asn_OER_type_Elevation_constr_1 CC_NOTUSED = { { 2, 0 } / (-4096..61439) /, // was {4, 0} before

Then I copied modified Elevation.c and also Elevation.h from /asn/its also to /asn/security and /asn/pki. Afterwards I was able to receive and send the generationLocation as expected. Are you implementing security v3 according to the mainstream or do you have something incompatible? I have no information about official release of the security, so maybe it's the time to put some common effort to make at least simple security v3 transmission functional in official release.

[Rom-1T]

Hello @valt2017,

I believe that the asn_oer_constraints_t should be set to {2,1} because the Elevation should actually be unsigned. The values are encoded between 0 and 65,535, and the interpreted value is then shifted. When the elevation is encoded as 0, it actually means that the elevation is -409.6 meters.

I finally resolved my issue. The problem was that Elevation is also defined in asn1/its. To prevent similar issues in the future, I suggest renaming some containers or values to avoid conflicts.

Best regards,