We are all aware of the current risks when developing a connected product, especially with vehicles since much is at stake both from an information and safety perspective. In this workshop, we will learn how to build Security requirements, architect, design, test and produce Safety and Security critical components using a methodology that works in harmony both with Engineering and Security

1. Best Of The World In Security Conference
Best Of The World In Security
12-13 November 2020
Hardware Security on Vehicles
Javier Vazquez Vidal
Hardware Security Expert
@fjvva

2. Best Of The World In Security
• Architecture, Production and Security background.
• Over 10 years of experience in Reverse Engineering (HW and SW)
• Worked on both sides (attacker, employee)
• Experience in Critical Infrastructure, Consumer/Military products and
Automotive.
Who am I?

3. Best Of The World In Security
Security during the entire life-cycle of a product:
• Requirements/Specifications
• Architecture
• Design (SW/HW)
• Prototyping and Testing
• Certification/Homologation
• Production
• EOL Testing/Programming
• Aftersales
What will we learn?

4. Best Of The World In Security
• Wrongly believed to only affect the Product itself.
• The goal of the Product Security team is to protect the IP, the safety
and privacy of the end users and prevent unauthorized use of the
company assets and IP.
• Product Security must cover the following aspects:
• Product Security architecture.
• Security investigations/forensics.
• Access to confidential resources regarding the product.
• Access to product sources (Code Repos / HW Projects).
• Access to development/testing processes and equipment.
• Access to restricted areas containing critical product assets.
• Heavy engagement with Engineering teams and suppliers.
What is Product Security (ProdSec)?

5. Best Of The World In Security
• Why is Product Security necessary?
• Security is not a one time task, it is an ongoing job.
• Security is a specific expertise that like any other expertise, requires
dedication.
• Besides all the “Cyber” security challenges that are rising, the classical ones
are still in place (such as IP theft/leaks). “Cyber” just means “IT outside of the
building”, which is a small part of the entire security.
• Bad media can kill a product or an entire brand.
• Not everyone that gains unauthorized access to your product or infrastructure
will contact you, make it obvious or public. There is a black market for
vulnerabilities.
What is Product Security?

6. Best Of The World In Security
• Unauthorized access to customer data.
• Unauthorized access to systems that “don’t exist”.
• Remote control/manipulation of vehicles/fleets.
• Accidents/Incidents caused by unauthorized yet undetected
modification of vehicle components by the end user.
• Vehicle theft.
• Product user profiling and tracking.
What are the Security threats in Automotive?

7. Best Of The World In Security
• When should they be defined?
• The optimal scenario is to define them together with functional
requirements.
• Engineering and Security teams MUST work together.
• Creating security requirements once the development stage has started is
likely to increase cost and prove inefficient in the future of the product.
Security Requirements, the starting point.

8. Best Of The World In Security
• What needs to be taken into account to define them?
• Functional requirements.
• Safety requirements (ISO26262).
• Privacy/Data protection legislations (GDPR).
• Product Life and Accessibility.
• Current attacks and tendencies.
• Available hardware.
• Marketing may sometimes be a factor.
Security Requirements, the starting point.

9. Best Of The World In Security
An example would be the requirement to protect user data.
Manufacturer A decides to do it as follows:
• In-vehicle system running Linux.
• Binary inside file-system encrypts and decrypts the user data, so it
only exists unencrypted in RAM. It is always encrypted on disk.
• Encryption key is stored inside the binary.
• Access to the Linux system is disabled (no ssh/telnet/shell).
Is the customer data secure?
Security Requirements, the starting point.

10. Best Of The World In Security
Manufacturer A realizes the problem and makes changes as follows:
• Binary inside file-system accesses an on-board Secure Element that
decrypts the key used to encrypt and decrypt user data, so it only
exists unencrypted in RAM. It is always encrypted on disk.
• User data encryption key is stored inside the binary, but encrypted.
• Encryption key used to decrypt the User data encryption key is stored
in Secure Element.
Is the customer data secure?
Security Requirements, the starting point.

11. Best Of The World In Security
The following aspects should be taken into consideration when
evaluating their scope:
• What is the role of the device?
• Is it critical to safety and/or security?
• Does the device interact with other safety/security critical devices or
infrastructure?
• Could the output of this device directly or indirectly influence the
behavior of the product or infrastructure in undesirable or dangerous
ways?
• How long does this product need to be supported?
• How accessible is this product to the end user?
Security Requirements - Scope

12. Best Of The World In Security
One of the biggest misconceptions in Automotive Security is to believe
that cars are “personal computers on wheels”. They are as much of that
as a “smart” doorbell is.
One of the key points to remember is that an Embedded System is NOT
a “Personal Computer”. The key difference is that a Personal Computer
is designed to be flexible on its uses depending on the software and OS
you install in it, where an Embedded system is designed with both
Hardware and Software specialized to serve ONLY an specific
application.
Security Requirements – Hardware –break this up

13. Best Of The World In Security
It is for this reason, the “logic” applied to IT security cannot be applied to
vehicle systems directly, which is a very common mistake.
An IT Pentester will find flaws in a navigation system that will have terrible
consequences, but can be patched with a firmware update. A Hardware
Pentester will find flaws that will be from difficult to impossible to fix without
a total system redesign and/or replacement.
Don’t forget that Hardware is the base of Security in embedded systems.
Software can always be installed/upgraded, but Hardware (with its
capabilities) is static once frozen. The main focus in Automotive Security
during product development should be the Hardware.
Security Requirements – Hardware

14. Best Of The World In Security
If this toaster has a paid plan to add “extreme toasting” functionality,
would it be secure if only the activation method (Cyber) had been
secured?
Security Requirements - Hardware

15. Best Of The World In Security
The optimal process to determine the best hardware that meets both
Functional and Security requirements is as follows:
• Engineering team creates Functional requirements and provides a set of
options for desired MCUs/MPUs to ProdSec.
• ProdSec evaluates the safety/security risks in the system, working together
with engineering, and creating the Security Requirements for it.
• ProdSec evaluates the Security Capabilities of all the provided MCU/MPU
options to see if any of them matches the Security Requirements.
• ProdSec determines the option to be used. If none of the provided options
meets the Security Requirements, ProdSec will provide options that meet
both Functional and Security Requirements.
Security Requirements – Hardware

16. Best Of The World In Security
*Important: The person/sub-team from ProdSec team must have a
clear understanding of Hardware Engineering and Functional
Requirements, as well as Embedded Security. Additionally, performance
testing will be required to make sure Functional requirements (such as
boot time and data persistence) are met.
Security Requirements – Hardware – break this up

17. Best Of The World In Security
• Software and data storage is critical to Hardware Security.
• In embedded systems, it is very straight forward and inexpensive to
access it unless properly secured.
Security Requirements – Software and Data

18. Best Of The World In Security
The key to properly securing the software is encryption, but not in a
classic way.
In Embedded systems, the following attacks need to be considered
when it comes to data extraction:
• Physical dump of memory.
• Physical dump of RAM.
• Reverse Engineering of Binaries.
• Physical access to all buses.
*Note: None of the above require access to the OS itself or code
execution.
Security Requirements – Software and Data

19. Best Of The World In Security
Some challenges that might be faced:
• Security engineers have a reputation of being difficult to work with.
• Engineering teams don’t enjoy changes, delays or working on things
they don’t fully understand.
Success cannot be achieved without a clear communication,
understanding and collaboration between Engineering and Security.
Security Requirements – Working with engineering teams

20. Best Of The World In Security
A few highlights to improve cross-functionality between both teams:
• Appoint specific individuals from each team to have meetings
together and discuss tasks and path forward.
• These individuals should be the ones that have a better
understanding of both worlds on each team.
• Have redundancy, do not let a single person represent a team.
• Both teams need to earn the trust of each other.
• Engineering teams should be empowered to directly interact with ProdSec to
ask for trainings, help with decision-making, and implementation of Security
Features.
• ProdSec should be granted access to any requested material, and effort
should be put into providing them what they need to do their job.
Security Requirements – Working with engineering teams

21. Best Of The World In Security
Security architecture does not start in the application layer. It starts with the
Hardware.
Most systems are compromised initially by hardware attacks, that enable further
attacks on the software layers after some Reverse Engineering.
Security Architecture

22. Best Of The World In Security
When it comes to Hardware, we want to be protected against the
following attacks:
• Data extraction/Manipulation
• FW/Memory dumps.
• User Data.
• Unauthorized FW downgrades (re-enabling exploits)
• Unauthorized access
• Shells/APIs on board test-points or pins/pads.
Security Architecture - Hardware

23. Best Of The World In Security
What is NOT Hardware Security:
• Leaving unpopulated components to data lines (resistors on UART).
• Scratching/obscuring the Part Number of components (MCU/MPU).
• Adding unnecessary HW such as “Domain Controllers” for Security.
• Not using the standard pinout for debug interfaces.
• Using an obscure sequence to enable debugging.
• Epoxy.
Security Architecture - Hardware

24. Best Of The World In Security
What IS Hardware Security:
• Blocking debugging access (ideally with authentication)
• Hardware Encryption and Key Storage capabilities (embedded HSM in MCU/MPU)
• eMMC/Flash FULL encryption
• RAM encryption
• Resistance to physical attacks:
• Side Channel
• Fault Injection
Security Architecture - Hardware

25. Best Of The World In Security
What needs to be considered in Hardware Security Architecture:
• Technology evolves, and so do computing power and attacks.
• Tools to perform complex attacks become more mainstream and inexpensive
• In Automotive, the entire system is physically available to the end-user.
• Avoid parts (MCU/MPU/HSM) that have been in the market for a while, as they
are more likely to have less effective security features. Always try to use the most
recent component that will be available before your product starts
Certification/Homologation.
• During the Architecture phase, acquire development boards for the Secure
MCU/MPU platform you want to use and run performance tests with all the
required security features enabled. Vendors will typically help with this.
Security Architecture - Hardware

26. Best Of The World In Security
• Media layers do not inherently offer security.
• Checksums, CRCs are not security features, but integrity verification features.
• Security on communication lines depends on the application layer.
• Communications redundancy is a MUST in Security Critical devices.
• Both encryption and authentication of data can be used, depending on the
security needs:
• Need to make sure data is not tampered/forged? -> Authentication
• Need to make sure data is not visible in plaintext? -> Encryption
• Both encryption and Authentication add processing overhead. Use only the
necessary means, and remember to benchmark your system to make sure it
meets the functional requirements.
Security Architecture – Communication lines

27. Best Of The World In Security
• In redundant systems (ISO26262), things become a bit more tricky if keys are
being rotated/updated. The approach taken should be the same as having
different keys per FW release.
• Secure Boot and Trust Zone are a must (where applicable).
• Hardware key storage and crypto-acceleration should be the first option.
• Software obfuscation is NOT security.
• We need to understand the difference between “Secure System” and “Source of
Trust”.
Security Architecture – Software

28. Best Of The World In Security
Security Architecture – Understanding Secure Boot

29. Best Of The World In Security
• Designing a complex secure system is not easy.
• All sub-systems should fall into one of the following categories:
• Safety Critical
• Security Critical
• Both
• There must always be a source of trust inside a complex system.
• If the source of trust fails, the system must still be usable.
• The engineers responsible for the design should have a basic
understanding of the security risks involved in their part of the
product.
System Design

30. Best Of The World In Security
We are designing a part of a system that will be critical to security. The
following system-wide requirements have been put in place:
• System must handle cryptography by HW.
• System must be able to handle complex OS and peripherals (DDR5,
PCIE GEN4 x16).
• System must be multi-thread capable.
The engineer/team responsible for this part has no understanding of
security, but is extremely talented in design. Can anything go wrong?
System Design - Example

31. Best Of The World In Security
What happens when you design a functional product that does meet
requirements:
*Most manufacturers relied on Intel's on-chip security features solely.
System Design - Example

32. Best Of The World In Security
What happens when you design your system to have a “non Cyber”
source of trust:
*CSME stands for Converged Security and Management Engine
System Design - Example

33. Best Of The World In Security
A few tips to take into consideration.
• Hiding/obscuring debug/configuration interfaces doesn’t work.
• Budget is important, but market loss is “importanter”.
• Thermal/Size is extremely important. The hotter a system runs, the
easier it is for faults to happen.
• Physical Location matters.
System Design

34. Best Of The World In Security
• There are always multiple ways to meet requirements, but not all of
them will be secure.
• Security requirements should be matched to functional requirements
in order to understand which team/individual is responsible for the
implementation.
• Security critical features should be developed in close collaboration
with the security team.
• Backdoors/Forensics features are necessary, but they should be
protected by complex security mechanisms.
System Design – Working with requirements

35. Best Of The World In Security
• Testing is not easy, specially when functional and security testing
need to work.
• Hardware testing implies that both the Security Requirements are
met, and that the behavior does not have any flaws.
• Compiled code does not always behave exactly like the source code.
• “Fuzzing” can be useful, specially when used to provide invalid inputs
and verify that the behavior of the system is as expected.
Testing

36. Best Of The World In Security
• Basic tests that must always be performed:
• Dumping Firmware (either through JTAG or physically).
• System behavior when bootloader/config pins are toggled.
• Bus sniffing.
• Data manipulation.
• Desirable tests:
• Fault Injection attacks
• Side Channel attacks
Testing – Hardware Security

37. Best Of The World In Security
• Basic tests that must always be performed:
• Data manipulation.
• Reads/Writes in excess.
• Breaking sequences.
• Desirable tests:
• Secure Boot.
• Code Review.
• Backdoors/Forensics access.
Testing – Software/Data Security

38. Best Of The World In Security
• A product has been developed with the following requirements:
• Source of trust for the entire vehicle.
• Protect Customer Data
• Advanced capabilities (Video/Audio)
• The chosen platform is NXP iMX6
• Offers HAB (High Assurance Boot)
• EMMC Encryption by hardware
• Secure key storage (blob)
• Vendor offers part manufactured in 2016 to be used in production.
Would this be acceptable?
Testing – Exercise

39. Best Of The World In Security
Once a product has been homologated/certified, introducing HW
changes would put the component at risk of having to be
homologated/certified again for the new revision.
This is inconvenient and expensive.
It is important to have the HW fully tested and validated by Security
team before this process starts.
Homologation/Certification

40. Best Of The World In Security
• Many sensitive data leaks originate in production.
• Specialized tools are used for initial configuration.
• Employees in production line are more prone to dissatisfaction.
• Security awareness training is important.
• Credentials/Internal networks are not enough.
Production – Security Risks

41. Best Of The World In Security
• Can the following be abused?
• Specialized tooling available to anyone enrolled in programs.
• Access to specific services that bypass security procedures.
• Can any of the following happen?
• Product delivered/returned with internal testing SW/FW.
• Product delivered with previous user/owner information.
• Internal SW/HW (engineering/beta) being installed in production units.
If the answer to any of the above is “yes”, then some work needs to be
done.
AfterSales – Security Risks

42. Best Of The World In Security
• A very well known product with more than 87 million units sold was
compromised (and still is) the following way:
• Employee from EOL testing leaked files and procedure used to put the
product into “test mode”. There was no economic or personal gain, other
than being unsatisfied with his employer and the desire to help individuals
that were reverse-engineering the security mechanisms of this product as a
personal challenge.
• Several units of this product were returned to customers after service with
“test firmware” still in them. These units were either donated to researchers
or sold on ebay for a high price.
AfterSales – Security Risks examples

43. Best Of The World In Security
• Another very well known product with more than 80 million units
sold was compromised (and still is) the following way:
• A unit was sent for repairs and returned executing “test firmware”.
• This unit was sold on ebay as “faulty” for a very inexpensive price.
• Security researchers had access to it and were able to reverse-engineer the
process used, which required no specialized tools to replicate.
AfterSales – Security Risks examples

44. Best Of The World In Security
• Always verify products flagged as “production” before they leave the
service center or factory.
• Rely on tested secure hardware for all security critical processes and
key storage.
AfterSales – Security Measures

45. Best Of The World In Security
Questions?

46. Best Of The World In Security
Thanks to CISOPlatform for their hard work to help the community.
Thank YOU for attending this workshop.
Twitter: @fjvva
Thank you everyone!