Preventing Car Hacks (Part 3): Coding & Testing Techniques and Physical Security

Preventing Car Hacks (Part 3)In Part 1 and Part 2 of this blog series, I addressed common vulnerabilities, explained how to use our Mocana Security of Things Platform to easily secure a car, and provided a checklist of system design techniques. But wait, there’s more!

In today’s post, I’ll discuss coding and testing techniques and physical security that, while familiar, are often overlooked with potentially disastrous results.

Follow Coding Best Practices

Although the security concepts that I described in part 1 of this blog series are necessary for preventing hacks, they are not sufficient by themselves. You must build your software and systems according to a body of best practices.

  • Simplify the design—Complexity is the enemy of safety and security. The simpler the design, the easier it is to build correctly and test thoroughly. Simplicity is the friend of safety and security.
  • Use a coding style guide—Just as journalists follow writing style guides, so should programmers following a coding style guide that spells out the requirements for development environment directory and file organization, naming conventions, declarations and types, error handling, white space formatting, memory management, library use, and so on.
  • Heed compiler warnings—Your compiler’s designers build in the warnings for a reason, not just to annoy busy programmers. It’s important to eliminate all warnings (by correcting the code, not simply changing to a lower warning level!) instead of just ignoring them. Warnings can help catch bugs before testing, which means the cost to fix the problem is reduced. Warnings catch bugs that are hard to find in testing, such as failing to return a value from a function. And if you maintain a warning-free codebase, and warnings all of a sudden start appearing, it’s easy to pinpoint which code is the problem.
  • Protect passwords and keys from leakage—Even the best authentication and strongest crypto algorithms cannot protect against code that writes its own passwords or keys to firmware or logfiles, where they can be viewed by almost anybody. Do not rely on compiler obfuscation; hackers are endlessly patient when it comes to reverse engineering and decoding strings of interest. To guard against such leakage, perform string searches on the firmware to ensure that there are no passwords or markers. And be sure to include log analysis in your test automation suite to ensure that passwords and keys are not revealed.
  • Implement a full-featured development environment—When single programmers developed applications in their garage, they could list bugs on scraps of paper. But with teams of developers and dozens, if not hundreds, or thousands of interacting and dependent software modules, it’s essential that both target and test code be managed with a suite of tools. At a minimum, you need a code repository for source code and test code; a bug tracking database, where version, component, module, bug priority, test case, and so on are dynamically and automatically maintained; and test machines, where test monkeys reside to automatically build and test code as it’s checked into the code repository.

Test thoroughly and completely

Security hack attempts are ever-present and ever-changing, and exploit a wide variety of vulnerabilities. To deal with this reality, it’s imperative to perform many types of tests. A full survey of test techniques is beyond the scope of this blog post, but here are a few key security-specific tests that should not be omitted:

  • Attack testing—Forces a program to perform actions on invalid or malicious data to revel what the program could allow an attacker to do. When you find an issue and apply a fix, keep looking for more cracks in the system (vulnerabilities).
  • Penetration testing—Attempts to compromise the security of a system or application by applying the same techniques that a hacker would use. If you think like a hacker and successfully hack the system, you can then modify the code and its design to prevent that sort of hack.
  • Fuzz testing—Provides fuzz (random data) to a program’s inputs, thereby finding bugs that occur in unusual situations outside the normal program flow and testing. You should employ a variety of fuzzers to target different entry points into an application, such as communications layers, file systems, and files.
  • Static code analysis—Analyzes source code or object code, typically by using automated tools, without actually executing programs. Distinct from code reviews, software inspections, or software walkthroughs, code analyzers range from lint-like utilities to code composition scans (such as Black Duck Suite) to architectural visualization tools. In addition, there are plugins for many popular integrated development environments (IDEs) that perform code inspections and project analysis. In addition to identifying specific issues, the metrics that are produced by static code analysis let you measure and improve the quality of the software.

Remember, security is not “do it and forget it.” You must be continuously on the lookout for variations of previous attacks, as well as new types of attacks. It can be particularly helpful to monitor attacks in adjacent markets, which you should assume will be repurposed and repeated against your device.

Physically Secure all Systems

It’s important to remember that physically securing a system’s interfaces can eliminate many security risks. For example, password-protected JTAG interfaces are vulnerable to timing attacks: an attacker can guess even a 16-byte password in only (2^8)*16 guesses if the chip is not resistant to timing attacks. But by disabling the JTAG interface, you prevent such attacks. As well, adding physical tampering evidence seals offers both deterrent and detection capabilities, further protecting a car’s systems.

Conclusion

In this series I’ve addressed common vulnerabilities and how to protect against them, provided a checklist of system design techniques to further harden a smart car system, and discussed some often overlooked coding, testing, and physical security techniques. When taken together, these recommendations will put you firmly on the path toward preventing car hacks.

Contact Us!