Login    1.866.392.4897   sales@timesys.com  

Secure, Connected Cars, Buses and Electric Vehicle (EV) and V2X Components using Embedded Linux

Modern cars contain up to 150 ECUs and about 100 million lines of software code* — four times more than a fighter jet.

As of January 2021, UN Regulations (WP.29) on Cybersecurity and Software Updates have become a requirement. And the National Highway Traffic Safety Administration (NHTSA) has released an update to their Cybersecurity Best Practices for the Safety of Modern Vehicles.

  • Designing vehicle security and keeping it secure enhances brand reputation.
  • Lack of awareness of vulnerabilities does not mean that vulnerabilities do not exist.
  • Keeping the software supply chain secure is vital to maintaining security throughout the vehicle production lifecycle.

*McKinsey & Company, “Cybersecurity in automotive. Mastering the challenge.” March 2020.

Secure, Connected Cars, Electric Vehicle (EV) and V2X Components using Embedded Linux

Secure, Connected Cars, Buses and Electric Vehicle (EV) and V2X Components using Embedded Linux

Modern cars contain up to 150 ECUs and about 100 million lines of software code* — four times more than a fighter jet.

As of January 2021, UN Regulations (WP.29) on Cybersecurity and Software Updates have become a requirement. And the National Highway Traffic Safety Administration (NHTSA) has released an update to their Cybersecurity Best Practices for the Safety of Modern Vehicles.

  • Designing vehicle security and keeping it secure enhances brand reputation.
  • Lack of awareness of vulnerabilities does not mean that vulnerabilities do not exist.
  • Keeping the software supply chain secure is vital to maintaining security throughout the vehicle production lifecycle.

*McKinsey & Company, “Cybersecurity in automotive. Mastering the challenge.” March 2020.

Timesys’ Security Solutions can shorten the development time of Connected Car and V2X Components using embedded Linux and RTOS that meet and exceed the cybersecurity standards and maintain strong product security throughout the production lifecycle.

Simplify meeting standards ISO/SAE 21434 and European WP.29 Compliance, and NHTSA Draft 2020 recommendations for Software and Firmware Security

Secure Vehicle By Design solution integrating best practice security features

Unique Software Composition Analysis (SCA) features, optimized for embedded systems, providing more accurate SBOM and streamlined vulnerability (CVE) management and long term maintenance

Software Engineering Services that excel in BSP (Board Support Package), UI, interconnected and multi-IO systems implementations

We work with Automotive OEM, Tier 1, 2, and 3 suppliers and semis (NXP, NVIDIA, Renesas, Qualcomm and ST) across a broad range of automotive products and capabilities, including:

  • In-Vehicle Infotainment (IVI)
  • V2V Communication (Telematics)
  • EV Charging
  • ADAS
  • Multi-display and Multi-camera
  • OBD
  • Firmware Remote Development Debugging and Testing

Auto-ISAC Automotive Cybersecurity Best Practices
Cybersecurity experts agree that a future vehicle with zero risk is unobtainable and unrealistic.*
The Best Practices provide an approach to vehicle cybersecurity management and mitigation throughout the entire vehicle lifecycle.

*Auto-ISAC Automotive Cybersecurity Best Practices Executive Summary – July 2019

 

Timesys Device Security Solutions enable you to streamline and simplify compliance with cybersecurity standards, regulations and industry guidelines.

Some of the key requirements addressed are:

  • NHTSA Draft 2020 Update – Vehicle Cybersecurity Best Practices:
    • 4.2.6 Inventory and Management of Software Assets on Vehicles
      • [G.10] Manufacturers should maintain a database of operational software components (SBOM) used in each automotive ECU, each assembled vehicle, and a history log of version updates applied over the vehicle’s lifetime. Note: These details could include: the licenses that govern those components, the versions of the components used in the codebase, and their patch status.
      • [G.11] Manufacturers should track sufficient details related to software components, such that when a newly identified vulnerability is identified related to an open source or off-the-shelf software, manufacturers can quickly identify what ECUs and specific vehicles would be affected by it.
    • 4.2.7 Penetration Testing and Documentation
      • [G.12] Manufacturers should evaluate all commercial off-the-shelf and open-source software components used in vehicle ECUs against known vulnerabilities [CVE Sources Mitre and NIST NVD]
    • 4.2.8 Monitoring, Containment, Remediation
    • 4.2.9 Data, Documentation, Information Sharing
    • 4.4 Security Vulnerability Reporting Program (collaboration)
    • 4.6 Self-Auditing
    • 8.1 Developer/Debugging Access in Production Devices
    • 8.7.3 Network Ports, Protocols, and Services
    • 8.8 Software Updates / Modifications
    • 8.9 Over-the-Air Software Updates
  • WP.29 UNECE Vehicle Regulations:
    • Securing vehicles by design to mitigate risks along the value chain;
    • Detecting and responding to security incidents across vehicle fleet;
    • Recording the hardware and software versions relevant to a vehicle type;
    • Identifying software relevant for type approval;
    • Verifying that the software on a component is what it should be;
    • Identifying interdependencies, especially with regards to software updates;
    • Identifying vehicle targets and verifying their compatibility with an update;
    • Assessing if a software update affects the type approval or legally defined parameters;
    • Assessing if an update affects safety or safe driving;
    • Informing vehicle owners of updates;
    • Documenting all the above.
  • ISO/SAE DIS 21434 Road vehicles — Cybersecurity engineering:

    A vulnerability analysis should be generated for each known vulnerability assessed or new vulnerability identified during cybersecurity testing. The disposition of the vulnerability and the rationale for the how the vulnerability is managed should also be documented.

    • [WP-07-04] (vulnerability analysis) should be generated for each vulnerability identified during cybersecurity testing.
    • [WP-07-08] (“Rationale for the managed vulnerability”) The disposition of the vulnerability and the rationale for the managed vulnerability should also be documented
  • ISO 26262 Road vehicles – Functional Safety:

    This is the adaptation of IEC 61508 and addresses potential safety vulnerabilities in electric and or electronic components like ABS, ADAS, ECU, Instrument Clusters and IVI. ISO 26262 requires use of better development lifecycle processes and tools to avoid or control safety and security vulnerabilities. The following principles help improve development processes:

    • Traceability and identification of open source components in first-party and third-party platforms (SBOM)
    • Management of cybersecurity vulnerabilities during design and after release to production
  • NIST 800-160 System Security Engineering:
    • Firmware
      Firmware exhibits properties of hardware and software. Firmware elements therefore adhere to the security implementation considerations of both hardware and software elements.
    • G.8.2 Assurance
      Not all vulnerabilities can be mitigated to an acceptable level. There are three classes of vulnerabilities in delivered systems:

      1. Vulnerabilities whose existence is known and either eliminated or made to be inconsequential;
      2. Vulnerabilities whose existence is known but that are not sufficiently mitigated;
      3. Unknown vulnerabilities that constitute an element of uncertainty— the fact that a vulnerability has not been identified should not give increased confidence that vulnerabilities do not exist.

      Identifying the residual vulnerabilities in the delivered system and the risk posed by those vulnerabilities, and having some sense of the uncertainty associated with the existence of the unknown residual vulnerabilities, is an important aspect of assurance.

Timesys Device Security Solutions

Timesys Device Security Solutions for open source embedded Linux

Secure By Design

Timesys Vigiles Secure By Design Services

Security services to accelerate and simplify your implementation of:

  • Secure boot and chain of trust
  • Encrypted storage
  • Secure firmware updates
  • Device security hardening: Bootloader, kernel and user space
  • Protected hardware ports: JTAG, serial
  • Secure world/trusted software development (e.g.: OP-TEE software)
  • Tamper protection
  • Key and certificate management
  • Industry security standard compliance

Stay Secure

Timesys Vigiles Vulnerability Management Solution

Software-as-a-service toolset developed by Timesys to provide:

  • Automatic generation of an accurate Software Bill of Materials (SBOM) for automotive devices running embedded Linux
  • Accurate vulnerability detection with SBOM filtering
  • Integration with Yocto, Buildroot, Timesys Factory build systems
  • Accurate, curated meta-data on software components for higher rates of vulnerability identification and accuracy, with fewer false positives
  • Streamlined remediation of vulnerabilities with efficient collaboration
  • Works out of the box with Automotive Grade Linux (AGL)

BSP Lifecycle Maintenance

Our turnkey BSP Lifecycle Maintenance Service bringing our team of embedded system software experts to manage all aspects of maintaining the OS of your embedded Linux BSPs. We take care of:

  • Monitoring and applying updates and patches, validating changes and providing you with reports on status
  • Maintaining the strongest security posture throughout device deployment
  • Providing you with ready-to-deploy platform updates
down arrow

Have a project you’d like to discuss?

Request Free Consultation