Fuzz Testing by ESCRYPT

The “Fuzz” on Automotive Cybersecurity Testing

With each passing year, vehicles become more complex and connected. In fact, International Data Corporation predicts that by 2023, nearly 70% of worldwide new light-duty vehicles and trucks will have embedded connectivity. In the U.S., the number is even higher – 90%.

While this connectivity provides consumers the driving experience they demand, it also significantly increases the vehicle’s attack surface – USB connections, connected entertainment, navigation systems and wireless systems. This makes vehicle cybersecurity testing even more critical to prevent criminals from stealing the vehicle and compromising vehicle systems, privacy, and safety of occupants.

Vehicle security testing comes in various forms:

  • Code audits
    As the name suggests, this is a comprehensive analysis of source code to discover bugs, security breaches or violations. Because approximately 90% of security issues derive from the coding errors, it is a valuable and popular testing method.
  • Penetration
    This simulated cyberattack evaluates the security of a system. Realistic in nature, it revolves around a person hacking in an ethical manner to find real-world vulnerabilities before production.
  • Functional security
    Similar to functional testing, this method ensures the software behaves as it should in various scenarios. For example, while the vehicle is moving, you shouldn’t be able to reset power steering to affect the driver’s ability to maneuver the vehicle.
  • Vulnerability scans
    This automated process, which is similar in nature to code audits, runs the system’s source code against known vulnerabilities. Because it’s a scan, it is known to miss some issues or have false positives.

A full-scale security test – fuzzing

Another testing method is fuzzing, an automated or manual process that checks software robustness by sending randomly generated input data, which may be bad, to the target to see how it responds and handles it. It’s a way to check the overall robustness of a system.

Fuzzers are made of two primary components: a message generator that creates an input for the target; and a target monitor that detects the misbehavior of the target.

Once a fuzzer is hooked up to a system and establishes solid lines of communication, the testing, which can take several days to weeks, can begin. Ideally the target is set up in a controlled environment with its own power source so the fuzzer can be monitored and controlled remotely to ensure proper and continuous operation.

Though not commonly used today, some automakers are starting to require its software suppliers to conduct fuzz testing. Although fuzz testing is simple, it offers a high benefit-to-cost ratio and can often reveal serious defects that are overlooked when software is written and debugged. Because of this, the full-scale testing of the system and accuracy of results it provides, experts expect fuzzing will become an industry standard with new software releases.

Third-party implementation

The new cybersecurity standard, ISO/SAE 21434, suggests fuzz testing be conducted by a third party because of the likelihood of more accurate and neutral results. In addition to accuracy and neutrality, ESCRYPT customers can rely on the company’s experience and knowledge of the automakers to help steer suppliers in a direction in line with OEM specific fuzz specifications, such as GM CG4579. “In fact, when a global automaker was looking for a CAN fuzzer to meet their requirements, ESCRYPT was the only supplier with the in-house testing tool, allowing us to provide a solution within one month.

Additional benefits of ESCRYPT’s fuzz testing:

  • Dynamic timeout
    If the target responds quickly, we move on to the next test case, whereas others will wait for the timer to run out. This efficiency allows more test cases to run and bugs to be found. Conversely, if the target doesn’t respond in time, we follow ISO standards to ensure we wait the appropriate amount of time to flag it as a failure.
  • Anomaly and instrumentation responses
    While most companies only look for a stack crash by checking the instrumentation response, ESCRYPT’s fuzzing also looks at the anomaly response and the instrumentation responses to provide a more comprehensive check for failures.
  • Support multiple database files
    ARXML, DBC, CDD, PDX
  • UDS and inverse UDS
    We test valid/ISO-standard, approved service ID (SIDs) as well as the opposite of these SIDs to find crashes.
  • Replay
    When a failure occurs, we can rerun the test for to check how reproducible it is. This is important since certain failures may not occur 100% of the time.
  • Flagging
    Our fuzzer flags issues in real time but we automatically go back and reanalyze with a computer to ensure it is a true failure and eliminate false positives. Many tools flag failures wrong due to incorrect timestamps in the logs, which confuses the fuzzer and requires someone to manually go back and determine if it’s a false positive.
  • Software-in-the-Loop (SiL)
    SiL allows us to fuzz test a target’s software without having the physical hardware present, allowing for fuzz testing early in the development lifecycle.
  • J1939
    Yes! We also support  J1939, which is a common standard in the heavy-duty truck industry.

ESCRYPT – your fuzzing partner

ESCRYPT has been providing fuzz testing to customers for over 5 years, giving us proven experience for accurate and reliable results. Our team uses our in-house fuzz tool for USB and CAN protocols to conduct specific customer products and for ongoing pilot projects. Other CAN fuzzers from well-known Tier 2 suppliers don’t provide test reports, defined test cases (requiring the engineer to write them), or pass/fail criteria. To talk to ESCRYPT about how our fuzz testing expertise can help provide your customers with safe and secure security software solutions, please contact us.

Leave a Reply