Developer Guide Release

Security Logging
OTA Log Upload
Copying Log Files From Security
Log File Format
Log Entry Description
IP Engine
CAN and CAN Over Ethernet
Logging Module
The security logging module is responsible for logging audit, system, and Communications and Security Services related events. This topic focuses on event logging within the security partition.
Modules within the security partition, such as CAN and IP engines, make use of event logging to log records generated in accordance with the specified requirements for:
Network traffic
Malicious codes
Known vulnerabilities detected
System integrity changes
Anti-malware events
For example, the IP engine forwards each received packet to be scanned and based on the scan event results and the policy configuration, it may invoke the logging of such events.
All logged even entries are subject to encryption before being written to files.
Up to four encrypted event files are generated in the security partition at:
Once event_log0.csv reaches a size of 5.24 MB, it is moved to a staging OTA folder (/nvseclog/ota/staging), then moved to /nvseclog/ota/upload to be ready for OTA upload. This is also the case if a timer (configurable and currently set to every 24 hours) kicks in.
Once event_log0.csv is moved, file event_log1.csv is generated and the above steps apply.
If moving the files to the /nvseclog/ota/staging folder is not successful for any reason, or in the event the last file, event_log3.csv, reaches the maximum size of 5.24 MB, a roll over occurs and event_log0csv is written into from the beginning.
OTA Log Upload
Uploading the event log to the OTA server is required. This occurs when the event log reaches its maximum size, or at the middle of the day if it does not reach the maximum size.
In order not to overload the OTA upload folder in case of communication breakdown (for example, an IVC transfer issue), the OTA staging folder is set to a limited size (this is configurable and currently set to 5 * maximum file size of 5.24 MB).
If the file is due to be uploaded to the OTA staging folder and the new file size + total OTA size exceeds the maximum allowed folder size, then older files are deleted, and the new file is moved over.
When the log is uploaded, the filename is appended with the time and date, and the log file is saved to the OTA upload directory within the security service.
For example:
is moved to the Communication Service directory at:
For example, a time-stamped event log filename has the format:
Copying Log Files From Security
If any log needs to be uploaded from Security VM on ad-hoc basis, make use of nvseccp (from the comms VM) or nvsecpush (from the security VM) applications.
nvseccp: In the comms VM, issue the following command:
# nvseccp /userdata/nvseclog/event_log0.csv
If successful, the log file is copied to the comms VM under /userdata/transfers/ and the following is printed on the console:
file copy success
nvsecpush: In the security VM, issue the following command:
nvsecpush /userdata/nvseclog/event_log0.csv
If successful, the log file is copied to the comms VM under /userdata/otavmclient/upload/ and the following is printed on the console:
file copy success
Once the log file is in the comms VM under /userdata/otavmclient/upload/, scp can be used to copy the file over the host PC:
scp /userdata/otavmclient/upload/event_log0.csv username@HOST_IP:/
Log File Format
The log file includes a header that describes each log entry as follows:
Project Name@ Partition Name@ Module Name@ Event Category@ Event Type@ Severity@ Event Outcome@ Reaction@ Date&Time@ Process ID@ Message1@ Count@
The header is followed by the actual logged data.
For example:
MAKO@ SECURITY PARTITION @ IP ENGINE @ SECURITY EVENT @ FIREWALL @ INFO @ SUCCESS @ NA @ 2018:09:13 11:00:05@ 200736@ [0] : event[1] = { id=5, code=7, value=0@ 1@
MAKO@ SECURITY PARTITION @ IP ENGINE @ SECURITY EVENT @ FIREWALL @ INFO @ SUCCESS @ NA @ 2018:09:13 11:00:05@ 200736@ [0] : event[1] = { id=5, code=7, value=0@ 100@
MAKO@ SECURITY PARTITION @ IP ENGINE @ SECURITY EVENT @ FIREWALL @ INFO @ SUCCESS @ NA @ 2018:09:13 11:00:05@ 200736@ [0] : event[1] = { id=5, code=7, value=0@ 300@
Log Entry Description
The logged data example provides a log from the Security Service firewall. the log entry is interpreted as follows:
MAKO: Project Name
SECURITY PARTITION: Partition Name (this is the security service)
IP ENGINE: Module Name (the module logging)
SECURITY EVENT: Event Category (category can be security, system, etc...)
FIREWALL -> Event Type (This can be any Packet scan service, such as Firewall, Deep packet inspection, Anti malware, etc.)
INFO: Severity
SUCCESS: Event Outcome
2018:09:13 11:00:05  Date&Time
200736: Process ID (The process logging)
100: Count (Number of times this same log has occurred. This is done to avoid repetitive logging)
The actual message logged from the firewall is as follows:
[0] : event[1] = { id=5, code=7, value=0@
[0]: The interface ID. These can be Ethernet, including VLAN, CAN, or AURIX interfaces.
event[1]: The event returned by the firewall scan which is acted on based on the policy. The result of the scan can be 1 or more event results.
id=5, code=7, value=0: consult IP Engine and CAN and CAN Over Ethernet for more details.
IP Engine
The firewall event ID is as follows:
FwEventFrameOk = 0,
FwEventFrameError = 1,
FwEventFrameIpv6 = 2,
FwEventFrameArp = 3,
FwEventFrameNotRecognized = 4,
FwEventFrameViolation = 5,
FwEventPcktNotRegistered = 6,
FwEventConnNotAvailable = 7,
FwEventIpBlacklisted = 8,
FwEventProtocolNotRecognized = 9,
FwEventPortNotAllowed = 10,
FwEventRepeatedAttempt = 11,
FwEventTcpConnError = 12,
FwEventTcpTimeout = 13,
FwEventFrameBroadcast = 14,
FwEventFrameMulticast = 15,
FwEventDhcp = 16,
FwEventIcmpFragment = 17,
FwEventUdpFragment = 18,
FwEventUdpZeroChecksum = 19,
FwEventDosLevel0 = 20,
FwEventDosLevel1Outbound = 21,
FwEventDosLevel1Inbound = 22,
FwEventDosLevel2Outbound = 23,
FwEventDosLevel2Inbound = 24,
FwEventDosLevel3Outbound = 25,
FwEventDosLevel3Inbound = 26,
The firewall event code is as follows:
FwCodeNone = 0,
FwCodeInfoCheckNotAvailable = 1,
FwCodeErrorChecksum = 2,
FwCodeErrorFrameLength = 3,
FwCodeErrorPacketLength = 4,
FwCodeErrorPayloadLength = 5,
FwCodeViolationLoopback = 6,
FwCodeViolationIpChanged = 7,
FwCodeViolationIcmpSmurf = 8,
FwCodeWarningPcktUntracked = 9,
FwCodeWarningTcpRegFailure = 10,
FwCodeWarningUdpRegFailure = 11,
FwCodeWarningIcmpRegFailure = 12,
FwCodeWarningAddrBlocked = 13,
FwCodeWarningPortClosed = 14,
FwCodeWarningTcpStateInvalid = 15,
FwCodeDosUdpFlood = 16,
FwCodeDosTcpFlood = 17,
FwCodeDosIcmpFlood = 18,
FwCodeDosUdpPortScan = 19,
FwCodeDosTcpPortScan = 20,
CAN and CAN Over Ethernet
The CAN firewall event ID is as follows:
FwEventOkCan = 0,
FwEventIdNotAllowedCan = 1,
FwEventInvalidFrameSizeCan = 2,
The CAN message frequency is as follows:
msgFreqOk = 0,
msgFreqIndef = 1,
msgFreqMalic = 2,
The CAN DPI is as follows:
DpiOkCan = 0,
DpiIndefCan = 1,
DpiMalicCan = 2,
Logging Module
The logging module implements a client server model with the client provided as a library to the modules that wish to log, such as IP or CAN. The implementation is performed by using the logging APIs.
Message queues are used to forward messages, such as log entries, from the client to the server. The logging server process, nvseclog_ser, is launched as part of the security startup script.
The logging server is responsible for:
Collating log entry messages
Invoking the encryption library to encrypt the contents before writing to the event logs
Logging APIs
To achieve logging of events, the logging client provides these APIs:
Scan event logging
void nvsec_scan_event_log(enum eventype etype, enum event_keyword_severity severity, uint64_t scan_type, uint16_t ifid, uint32_t event_id, uint32_t code);
Configuration event logging
void nvsec_cfg_event_log(enum eventype etype, enum event_keyword_severity severity, enum cfg_code_fail err_code);
Policy configuration event logging
void nvsec_policy_event_log(enum eventype etype, enum event_keyword_severity severity, enum policy_cfg_code_fail err_code);
Inter-Virtual Machine (IVM) logging
void nvsec_ivm_event_log(enum eventype etype, enum event_keyword_severity severity, uint8_t * msg_data);
eventType: defines the type of the event from different event categories.
keyword_severity: defines the severity where the security events are logged by the user.
scan_type: identifies the type of scans. Possible scans can be: Firewall, Frequency, or DPI.
if_id: represents the interface ID.
event_id: Identifies the ID of the event from the scan performed.
code: identifies the related event code.
Logging Encryption and Decryption
Event log entries are encrypted on-the-fly prior to being written to the event log files. Encryption of the event logs are achieved using the secure SEA engine. The resulting event log files are created in the security partition at:
If debugging is required, to read through, the files must be decrypted.
Since encrypted event logs are decrypted by the central OEM server, the decryption must be achieved on a host system NOT on the target hardware system. The secure engine AES is NOT available for decryption. Use OpenSSL to decrypt on the host Linux system.
To decrypt using OpenSSL
1. On the host system, navigate to the test application at:
<host_ip> is the IP address of the Linux host system.
<top> is the QNX top directory.
2. Copy the encrypted event logs from the Communications partition to the nvseclog_ssl_decrypt directory as follows:
Copy the event log files from /userdata/otavmclient/upload to the host directory at:
Execute this command to begin the decryption.
./nvseclog_ssl_decrypt <file(s) to be encrypted>