Files
MicrOBU/obu-firmware/external/vanetza-idf/docs/idf/evidence/security-host-06/analysis.md
T
Ashin Walpola d107534eb2 Keep vanetza-idf in obu-firmware, so a plain clone builds the firmware
obu-firmware builds against the vanetza-idf C-ITS library, which until now
came from the colleague's microbu-esp32c5 tree beside the repository and was
not tracked here, so a clone of this repository could not build the firmware
it ships. The library alone is now part of obu-firmware, as
obu-firmware/external/vanetza-idf: their external/vanetza-idf at commit
cf4b99f, unchanged (9775 files; see its PROVENANCE.md). CMake takes it from
there by default; -DVANETZA_IDF_DIR still points the build elsewhere.

The rest of the colleague's tree (their own VAM firmware, PKI tooling,
station-link Python tools, the V2X2MAP bridge) stays out of this repository
and gitignored; nothing is pushed to their repository. NOTES.md, docs/06,
TODO.md and the pcap verifier's usage line point at the new location.
2026-09-24 10:56:05 +02:00

2.6 KiB

security-host-06: AtsSecurity, GN-MGMT profile (sending side)

Campaign (re-run of security-host-03 with the SUT built with VIDF_SECURITY_VERIFY and the pool carrying CERT_TS_B_AT): ports/esp_idf/tests/etsi_security_gn.cfg (8 cases), host SUT vidf_sut --security-pool ./certificates (native Linux build, VIDF_SECURITY=ON), pool generated by vidf_test_pool (hashes in result.json, pool_sha256). The adapter enforces the framework's own verification of every IUT transmission (enable_security_checks=1, see test.cfg); a PASS therefore covers a signature the framework verified against CERT_IUT_A_AT from the pool, not only the message structure.

Case Verdict Cause
TC_SEC_ITSS_SND_GENMSG_01..04, 06..08 pass secured beacons (psid 141), TS 103 097 clause 7.1.3 profile
TC_SEC_ITSS_SND_GENMSG_05_BV fail ATS implementation defect, IUT-independent (below)

TC_SEC_ITSS_SND_GENMSG_05_BV

The testcase (pinned ItsSecurity_TestCases.ttcn line 7313) compares the signer certificate's validityPeriod.start (a Time32, seconds since 2004-01-01) against a range built from v_curTime in microseconds:

match(v_signerIdentifier.certificate[0].toBeSigned.validityPeriod.start_,
      Time32:(v_curTime - c_timeLimit / 1000000 .. v_curTime + c_timeLimit / 1000000))

Only c_timeLimit is scaled to seconds; v_curTime (f_getCurrentTime() * 1000) is not. Values from the MTC log of this run:

Quantity Value Unit
v_curTime 716441445225000 µs
range checked 716441445224700 .. 716441445225300 (µs magnitude)
validityPeriod.start_ 716440640 s
generationTime 716441450220842 µs (= 716441450 s)
duration 24 hours

No Time32 can fall into a range of that magnitude, so the branch fails for every IUT. The test purpose quoted in the testcase header (TS 103 096-2: X_START_VALIDITY <= GEN_TIME and duration > GEN_TIME - X_START_VALIDITY) holds for the observed values: 716440640 s <= 716441450 s and the difference (810 s) is below 24 h. The current upstream head of the Security ATS (forge.etsi.org/rep/ITS/ttcn/ats_sec_ts103096-3, branch master, line 6672) carries the same expression. The verdict is retained as recorded; the testcase was not modified.

Time base note

The framework's base_time derives ITS time from UTC without the five leap seconds inserted since 2004; the SUT clock driven by the adapter is TAI-based (IEEE 1609.2 Time64), hence the constant 5 s offset visible in the generation time check lines of console.txt (well inside the 30 s window the framework applies and the 5 min window of the testcases).