BGSV Embedded Academy (BEA)

Focused Program to Develop Embedded Competence

BGSV EMBEDDED ACADEMY

Technical Methodological
Process Competence
Competence Competence
T1: Automotive Basics
(Sensor, SW, Mobility P1: Requirements
M1: SW Development Engineering
Solution) Lifecycle
T2: Automotive SW
Architecture (AUTOSAR) P2: Design Principles

T3: Embedded Programming P3: Review

M3: Clean Code

T5: Test Overview P4: Safety & Security

Classroom training, Online Self-learning, Live Demo

Purpose: Develop basic general embedded competence
Disclaimer

 This slide is a part of BGSV Embedded Academy (BEA) program and only used for
BEA training purposes.

 This slide is Bosch Global Software Technology Company Limited’s internal property.
All rights reserved, also regarding any disposal, exploitation, reproduction, editing,
distribution as well as in the event of applications for industrial property rights.

 This slide has some copyright images and text, which belong to the respective
organizations.
 P4
SAFETY & SECURITY
Agenda

 Functional Safety
 Cyber Security

.
Functional Safety Introduction
Agenda
Content Timeline
Examples: 15 mins
✓ Boeing 737 MAX grounded
✓ Tesla Model 3 crashes into overturned truck on highway
Functional Safety Awareness 60 mins
✓ Challenges and Motivations of Safety
✓ Introduction to Functional Safety and ISO 26262 Standard
✓ Approaches to ISO 26262
Groupwork: 15 mins
✓ Create safety requirements for AEB function
Safety Culture 10 mins
Conclusion and Q&A 5 mins
Training Post-Test 15 mins

.
Functional Safety Introduction
An Example: Boeing 737 MAX grounded
The Boeing 737 MAX passenger airliner was
grounded – 346 people died in two crashes
▪ Lion Air Flight 610 on October 29, 2018
▪ Ethiopian Airlines Flight 302 on March 10, 2019

.
Functional Safety Introduction
An Example: Tesla Model 3 crashes into overturned truck on highway

Autopilot Blamed for Tesla’s Crash

Into Overturned Truck
▪ According to the driver Auto Pilot
function was active but not slowed
down neither for the pedestrian nor
for the truck.
▪ Source:
https://www.thedrive.com/news/337
89/autopilot blamed for teslas crash
into overturned truck

.
FUNCTIONAL SAFETY
AND
ISO 26262 STANDARD
Functional Safety Introduction
Challenges with Automotive Industry
Challenges to meet:
Safety
Security
Comfort
Automation
Efficiency
Performance
Less Pollution & etc.

▪ Increasing complexity of functions

▪ More and more distributed development
▪ Rising liability risks, such as safety and
security
Image from: Thomas Scannell, Automotive Lead, Amphenol Commercial Products

.
Functional Safety Introduction
Motivations: Malfunction and its impacts
▪ System and processes must NOT harm human
beings
▪ OEM has to ensure that, the design, production
and related faults are adequately detected and
mitigated by effective way

Adverse
effects of
the
Possible Impacts Rework of
Schedule

Legal Impacts High

implications of Costs
I1 I2 I3 I4 I5 for OEM in involved in
Vehicle
case of a Recalls
Driver and Ego Vehicle Environment Other
mishap Recall
other and other and Road OEM
passengers Vehicles Infrastructure Users

Brand
Reputation

.
Functional Safety Introduction
Motivations: Malfunction and its impacts
We do not want to be in the media with comparable headlines

.
Functional Safety Introduction
Motivations: Why Product Safety?
 Market Trends
Increasing complexity of devices has increased the inherent risks using them.
 Legal Regulations
Governments worldwide have defined laws and regulations to monitor and implement
safety of product and processes.
❖ §1 Liability (Main clause)
If somebody is killed by the failure of a product, his body or his health is injured or a thing
is damaged, the manufacturer of the product is obliged to substitute the damage to
the injured person.
 Consumer Awareness
Increasing consumer awareness of expected safety standards can adversely affect
organization companies that ignore Product Safety.

.
Functional Safety Introduction
Product Safety
 A product should be designed and manufactured so that it does no harm to the consumer or
damage the property of the consumer

 Product Safety is the freedom from unacceptable risk of harm, this means safety which could be
expected legitimately by the general public

 Safety vs. Security:

Avoiding of Protection against

Security Attacks danger, loss, criminals

Safety hazards failure, damage, error, accident

.
Functional Safety Introduction
Functional Safety

Functional Safety *
absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems
*definition according to ISO 26262-1:2018, 3.67

 Is a subset of Product Safety Product Safety

 For the consumer, it implies: Functional
 The product operates correctly in response to inputs Safety
 It poses no unacceptable risks even in failure conditions
 Functional Safety does not address performance aspects (e.g. noise during ESP control)
 In Bosch products (e.g., ESP, iBooster, Airbag, RADAR), wrong system behavior or unexpected
breakdown of system may influence the controllability of the vehicle. Persons may be endangered.

.
Functional Safety Introduction
The Standard ISO 26262
 ISO 26262:2011 (first edition) is an International Standard for
the automotive industry, based on the generic Functional
Safety Standard IEC 61508
 ISO 26262:2011 is the first edition for passenger cars, published
November 2011
 ISO 26262:2018 is the second edition expended for trucks, buses
and motorcycles, published December 2018

 ISO 26262 is NOT a law, but it can support to avoid product liability issues
 Deals with functional safety topic to minimize occurrence and consequence of road accidents due to
E/E and software
 Provide systematic development process and has high demands on technical requirements, process
documentation and analysis

.
Functional Safety Introduction
Scope of the Standard ISO 26262 & Product Life-Cycle
 ISO 26262 includes requirements for
 development processes and organization, Functional Safety Management Activities
i.e. Functional Safety Management
Concept Development Production and
 technical requirements for system, HW Phase Phase Operation
and SW levels
 The complete product life cycle is addressed
 system-description concept System
development
 hazard analysis phase
HW & SW
 system development development development
 HW- and SW-development phase
 production
 operation production and
 service operation
 decommissioning

.
Functional Safety Introduction
Structure of the ISO 26262:2018
Part 2: Functional Safety Management Activities

Part 3: Concept
Phase Figures:
Development
Phase 12 parts
Part 7:
> 800 pages
Production and
Part 4: System level > 600 requirements
Part 12: Operation
Part 5: Hardware level
Adaptation for Part 6: Software level ~70% are addressed by
Motorcycles CMMI level 3 (or similar like SPICE)

Part 8: Supporting Processes

Part 9: Safety Analysis

.
Functional Safety Introduction
Approaches to ISO 26262

Functional Safety *

absence of unreasonable risk due to

hazards caused by malfunctioning
behavior of E/E systems.
*definition according to ISO 26262-1:2018, 3.67

.
Functional Safety Introduction
Approaches to ISO 26262: Definitions
 Item: system or combination of systems, that implements a function or part of a function at the
vehicle level
 Element: Either a system, a component (consisting of hardware parts and/or software units)
 System: set of components or subsystems that relates at least a sensor, a controller and an actuator
with one another

 Fault: Abnormal condition that can cause an element or an item to fail

 Error: Discrepancy between a computed, observed or measured value or condition, and the true,
specified or theoretically correct value or condition
 Hazard: Potential source of harm (physical injury or health damage) caused by malfunctioning
behavior of the item
 Risk: Combination of the probability of occurrence of harm and the severity of that harm
 Safety Goal: Top-level (vehicle level) safety requirement as a result of the hazard analysis and risk
assessment
.
Functional Safety Introduction
Approaches to ISO 26262: Definitions
Accelerator Pedal Sensor
Harm: Injury to
pedestrians

Car Engine
Engine Control Unit

Code mistake

Harm /
Fault Error Failure Hazard
Accident
Fault: Too high Error: Engine control unit Failure: Excessive Hazard: Too high drive
accelerator pedal value provides too high torque engine torque output torque (vehicle
request to engine acceleration)

.
Functional Safety Introduction
Approaches to ISO 26262: Hazard Overview
headlights control missing activation
wheel torques
steering angle / torque
brake torque: too low / high
faulty drive torque: too low / high
hold force: missing / unintended
asymmetrical wheel torques
→relevant effect yaw torque: too low / high
driver information supply
airbag firing
INFO
missing or wrong unintended firing
missing firing

brake lights control

missing control (not switched on while braking)
unintended control is not considered as an hazard

.
Functional Safety Introduction
Approaches to ISO 26262: Malfunction of E/E system
Systematic Failure
 Failure, related in a deterministic way to a certain cause, that can only be eliminated E/E
by a change of the design or of the manufacturing process, operational procedures, System
Malfunction
documentation or other relevant factors
 Example: Wrong messages from ECU at the CAN bus because an obsolete
message format has been used
 Appropriate Development Process (e.g., review method, test method) is defined for
each ASIL level by the ISO Random
Systematic
Hardware
Random Hardware Failure Failure
Failure
 Failure that can occur unpredictably during the lifetime of a hardware element and
that follows a probability distribution Failure Hardware Software
Cause
 Example: in ECU RAM memory, stored bit permanently stuck at the same value (0
or 1) Systematic

 Target value of failure rate is defined for each ASIL level by the ISO Random
 NOTE: Random hardware failure rates can be predicted with reasonable accuracy

.
Functional Safety Introduction
Approaches to ISO 26262: Risk and Reasonable Risk Level
reasonable risk level
frequency of system
severity for system failure
risk = failure causing inju- • <
(weighting factor) causing injuries of
ries of severity level
severity level

S: Severity of possible accident

ASIL

→Potential injuries as a result of a hazard.

E: Probability of Exposure to driving situation

C: Controllability by the driver

λ : Failure rate
ASIL is determined to specify the item's necessary (functional) safety requirements for achieving an unavoidable residual risk

Systematic Failure
risk = ASIL f(S, E, C) • Failure rate

Random Hardware Failure

.
Functional Safety Introduction
Approaches to ISO 26262: Risk and Reasonable Risk Level
always

The combination of probability

and severity of dangerous
system failures must not exceed
Controllability C1..C3

the tolerable risk level!

Exposure E1..E4
Frequency

combined with

Finally, we must be on
this side of the
diagram (i.e. absence
of unreasonable risk)!
remote

easy

negligible Severity catastrophic

.
Functional Safety Introduction
Approaches to ISO 26262: ASIL (Automotive Safety Integrity Level)
 ASIL is a degree about the risk potential of a function in case of malfunction.
 ASIL is the grade for implementation of processes and metrics.

ASIL Classification

A B C D
Lowest Highest

 For the further implementation of ISO 26262 the ASIL classification must be known Following
classifications are possible:
 QM → no safety relevance according ISO 26262
Processes according usual QM system (ISO/TS 16949 or ISO 9001 certification) are sufficient
 ASIL A … ASIL D → Processes according ISO 26262

.
Functional Safety Introduction
Approaches to ISO 26262: ASIL (Automotive Safety Integrity Level)
 ASIL requires the identification and categorization of hazards by a malfunction of the system. This is
done by the method “Hazard Analysis and Risk assessment (HARA)” using the following risk
parameters:
 Exposure: How often do the driving situations occur, in which a driver or other road users can pose a hazard?
 Controllability: How well can the driver or other road users control the hazard in this driving situation so that
damage can be avoided?
 Severity: When damage occurs, what is its severity?

 The outcome if this Hazard Analysis and Risk Assessment helps us in deriving corresponding
ASIL

.
Functional Safety Introduction
Approaches to ISO 26262: Risk Parameters
 Severity (S)
Class S0 S1 S2 S3
Description No injuries Light and moderate Severe and life- Life-threatening
injuries threatening injuries injuries (survival
(survival probable) uncertain), fatal
injuries

 Exposure (E)
Class E1 E2 E3 E4
Description Very low probability Low probability Medium probability High probability

 Controllability (C)
Class C1 C2 C3
Description Simply controllable Normally controllable Difficult to control or
uncontrollable

.
Functional Safety Introduction
Approaches to ISO 26262: ASIL Determination

.
Functional Safety Introduction
Approaches to ISO 26262: Hazard Analysis and Risk Assessment
Hazard Analysis helps to determine
the safety assurance level (ASIL) by
characterizing the effects of its
failures on the Traffic participants.

ASIL-classification determines requirements to the

development

.
Functional Safety Introduction
Approaches to ISO 26262: HARA with Concept of ASIL
always

Risk reduction due to

Initial risk level before external measures e.g
development phase Controllability by the driver
Frequency

Automotive Safety
ASIL Integrity Level
(i.e. necessary risk reduction)

Achieved risk level at Reasonable

release for production Residual Risk
remote

Probability of Exposure to
driving situation

Severity of possible accident

negligible Severity catastrophic
.
Functional Safety Introduction
Approaches to ISO 26262: HARA → ASIL Rating
always

E*C=1 QM* B C D

E*C=0,1 QM* A B C
Frequency

E*C=0,01 QM* QM A B

E*C=0,001 QM* QM QM A

E*C=0,0001 QM* QM QM QM
remote

E*C=0,00001 QM* QM QM QM
S0 S1 S2 S3
negligible Severity catastrophic
.
Functional Safety Introduction
Example: Vehicle Hold
 Driving situation: Vehicle is parked on slope, driver outside car
 Failure on vehicle level: unintended vehicle movement (due to too low holding force @ wheels)
 Failure on ESP system level: no or too low brake pressure @ wheel brakes
 Maximum ASIL rating: ASIL C
If an impact speed higher 30 km/h possible. *)
Severity S3

Situation ‘hill hold’: Vehicle is parked (ignition off, driver absence) on a

slope **) threshold > 15%
Exposure E3

No controllability due to driver absence.

Controllability C3

 Safe state: Vehicle at standstill ASIL C

.
Functional Safety Introduction
Example: Vehicle Hold
 Driving situation: Vehicle hold on slope, driver inside car
 Failure on vehicle level: unintended vehicle movement (due to too low holding force @ wheels)
 Failure on ESP system level: no or too low brake pressure @ wheel brakes
 Maximum ASIL rating: ASIL QM

If an impact speed of 30 km/h or less is assumed the pedestrian or

cyclist will suffer an injury of 5 or 6 in less than 1% of the cases. *)
Severity S2

Situation ‘hill hold’: Vehicle is stopped on a slope **) threshold > 5%,
velocity can increase considerably up to 30 km/h before hitting an
Exposure obstacle in the environment.
E3
Analogue is the case steep slope (E2) with higher severity (S3)
Driver is simply controlling the vehicle.
Controllability C1

 Safe state: Vehicle at standstill QM

.
Functional Safety Introduction
Safety Concept / Requirements Flow
Hazard Analysis and Risk Vehicle level
Assessment (HA&RA) (Responsibility: OEM)
Specification of
Safety Goals

Functional Safety Concept

OEM requirement
Specification of specification
Functional Safety Requirements

System level
Technical Safety Concept
(Responsibility: e.g. RB)
Specification of
Technical Safety Requirements

Hardware Safety Concept Software Safety Concept

Specification of Specification of
Hardware Safety Requirements Software Safety Requirements

.
Functional Safety Introduction
Groupwork: Create safety requirements for AEB function
Automatic Emergency Brake (AEB)

◼ Automatic brake intervention if an emergency situation Reduced

is detected v consequences
◼ DAS detects emergency situation and sends DAS 3 due to reduced
1 t before crash speed
deceleration request to ESP (trigger time)
◼ ESP controls wheels pressures to decelerate vehicle 4
t
up to maximum possible reduction of vehicle speed
AEB active 2 Crash

Input parameters AEB

1
◼ DAS trigger signal
◼ DAS target deceleration
Output parameters
◼ Controlled brake pressure build-up at all wheels
◼ Brake light activation
◼ Wheel speed t
◼ Master cylinder
Pre-fill Active pressure build-up
pressure
QUESTIONS:
What are Safety Requirements for AEB function?
a) At vehicle level?
Driver Assistance System
b) At system level (DA and ESP systems)?
1

.
Functional Safety Introduction
Groupwork: Hazard Overview
headlights control missing activation
wheel torques
steering angle / torque
brake torque: too low / high
faulty drive torque: too low / high
hold force: missing / unintended
asymmetrical wheel torques
→relevant effect yaw torque: too low / high
driver information supply
airbag firing
INFO
missing or wrong unintended firing
missing firing

brake lights control

missing control (not switched on while braking)
unintended control is not considered as an hazard

.
 Functional Safety Introduction
Groupwork: Create safety requirements for AEB function
Vehicle Function

Avoid too Avoid too Avoid Avoid wrong

Avoid too Avoid too high Avoid
Avoid too low high or Avoid too low high or missing or missing
low drive or unintended unintended
brake torque unintended holding force unintended control of information
torque drive torque holding force
brake torque yaw torque brake lights to the driver

ASIL D ASIL C ASIL A ASIL B ASIL B ASIL A ASIL D ASIL B **

DAS: ESP: ESP: ESP: ESP: ESP: DAS: ESP:

Avoid Avoid Avoid Avoid Avoid increase Ensure Ensure Avoid missing
missing or missing brake unintended of propulsive controllability controllability of brake lights
too low or too pressure deactivation torque request and stability of the vehicle after during AEB
brake low decrease of propulsive during AEB. the vehicle after emergency intervention.
request brake due to AEB torque. emergency braking to
Involved Systems

intervent function. braking to standstill.

ion. standstill.
QM ASIL D ASIL D ASIL A ASIL B ASIL B ASIL A ASIL B

DAS: ESP: DAS: ESP: DAS: DAS: ESP: DAS: HMI:

Avoid unintended Avoid The system The system shall Ensure stability Avoid AEB Ensure the The system Avoid sending
brake torque unintended or shall ensure the ensure the of the vehicle intervention in steerability shall avoid wrong or
requested (false too high braking override override after situations where the and vehicle sending wrong missing
positive) within outside of capability of the capability of the emergency vehicle stability may stability while or missing information to
functional limits of functional limits driver with driver with braking to be compromised due function is information to the driver.
AEB (vehicle of AEB. respect to the respect to the standstill. to the AEB active. the driver.
remains steerable) braking system. braking system. intervention.
ASIL B ASIL C ASIL B ASIL C QM ASIL B ASIL D QM QM

.
Functional Safety Introduction
Approaches to ISO 26262: Principles
The combination of probability and severity of dangerous system
failures must not exceed the reasonable risk level

Requirements towards safety of the system functions = Functional Safety

Protection against “Systematic Failure” Protection against “Random HW Failure”

Development goal: "Robust Process“

Development goal: "Robust Design"
"Avoid systematic failures during design,
"Control dangerous HW failures during operation"
production and operation of the system“

Analytical/constructive measures Technical measures

e.g. methods / tools, guidelines, reviews, e.g. monitorings, failure management,
checklists, tests, etc. redundancy, preventive measures, etc.
Addressed by Process Landscape Addressed by Safety Requirements

.
Functional Safety Introduction
Approaches to ISO 26262: Recommended Process & Requirements
Requirements to Avoid and Control
Systematic Failures
QM ISO/TS 16949
ASIL A ISO 26262 conform development process
ASIL B ISO 26262 conform development process
ASIL C ISO 26262 conform development process,
assessment required, stricter processes compared
to ASIL A, B with respect to, for example, design
assurance and verification
ASIL D ISO 26262 conform development process,
assessment required, most comprehensive
requirements with respect to development
processes, design assurance, and verification
.
Requirements to Detect and Control
Random Hardware Failures
Residual Risk Reduces
No additional requirements
Effort Increases
Low demand for safety mechanisms, quantitative
or qualitative analysis. As a result, limited
requirements to hardware reliability and
monitoring concepts
Quantitative and qualitative analysis required,
effectiveness of implemented safety mechanisms
(e.g. monitoring concepts) must be evaluated
Category with lowest residual risk. In addition to
ASIL C, stricter requirements for hardware
reliability and comprehensive diagnosis and
monitoring concepts
SAFETY CULTURE
Functional Safety Introduction
What is the problem?
 Traditional safety engineering approaches developed for relatively simple electro-mechanical
systems
 New technology (especially software) is allowing almost unlimited complexity in the systems we are
building
 Complexity is creating new causes of accidents
 Should build simplest systems possible, but usually unwilling to make the compromises necessary
‒ Complexity related to the problem itself
‒ Complexity introduced in the design of solution of problem
 Need new, more powerful safety engineering approaches to dealing with complexity and new causes
of accidents
 One aspect: Increase Safety Culture !

© “The Role of Complexity in System Safety and How to Manage It”, Nancy Leveson, MIT,
https://www.google.de/search?q=safety+culture+nancy+leveson&ie=utf-8&oe=utf-8&gws_rd=cr&ei=5wgJVs-0Icb5ygPjtaj4Aw

.
Functional Safety Introduction
Real examples of a “bad safety culture”

I‘m here because of

missing message CRC
in
safety relevant system !

.
Functional Safety Introduction
Safety Culture: Problem Summary
 Most accidencts in all industrial areas are also caused by human
factors
 Gaps in process development (e.g., bad coding style and no sufficient
testing)
 Suppression of facts (e.g., no awareness to problem solving)
 Missing awareness to malfunction which are not covered by given
standards (e.g., unwanted AEB activations caused by functional
insufficiencies)

 Very often there exist the mindset "safety is done by one person"
and is covered parallel to the standard development process

© Nancy G. Leveson: „Managing Technical Risk and the

Safety Culture on Your Project”

.
Functional Safety Introduction
Safety Culture for new engineers
Takes Safety Policy seriously
Resources are allocated for safety to whole organization Commitment from S
Knows the significance and importance of safety standards Top Management a
f
e
Takes accountability of safety in project t
Commitment from y
Resources are allocated for safety to all project members
Project
Safety experts are named for all relevant system functions C
Management
u
l
t
Keeps questioning attitude u
Development confirm to process landscape r
Commitment from e
Takes accountability not only for function also for malfunction
Developer
Takes accountability of safety in their scopes and
fix/communicate all recognized gaps, even outside their scope
.
CYBER SECURITY
Introduction
Challenge
 You are a new hacker. Your first assignment is hacking a new
electric car with many modern features.

.
Introduction
Car Hacking Demo
Hackers Remotely Kill a Jeep on a Highway | WIRED

COSIC researchers hack Tesla Model X key fob

Tesla Model S Gets Hacked by Professionals

.
Introduction
Car Hacking Demo

.
Introduction
Threats & Motivation – Automotive World

Jeep Cherokee

Hackers Remotely Kill a Jeep

on the Highway - With Me in It

.
Introduction
What is Cyber Security
 Technologies, processes, and practices designed
to protect
networks, devices, programs, and data
from attack, damage, or unauthorized access.

.
Introduction
Why Cyber Security is not mandatory in the past
 Car is single entity without connectivity
 Car hacking requirements:
 Physical access
 Very expensive technical equipment
 High skill set required
 Car hacking benefits:
 Engine tuning
 More functions
 …

 Therefore, no special consideration regarding Cybersecurity in the automotive industry

until recently because ☛ The effort was too high compared to the benefit.

.
Introduction
Why do we need Cyber Security today

Source: www.microcontrollertips.com

.
Introduction
Why do we need Cyber Security from today
Increasing Communication Known weaknesses, High consequential
Attacks, Viruses,
& Complexity, Attack potential costs, image
Trojans, Accidents
Open Interfaces demonstrated damage

Embedded (Automotive) 2005 today

Telecommunication 2000 2005 today

IT-Infrastructures 1985 1990 1995 today

time

 Publications and evaluations show attack potential at reasonable costs

 Potential for internal and physical attacks
 Increasing attack surface (vulnerable interfaces)
 Leveraging effects: Initial, complex, physical “exploring” attacks opens easily
attackable weakness (manipulated audio files...)

.
Introduction
Why do we need Cyber Security from today
 Country or global standard
 UNECE WP.29 timeline: 7/2022, 7/2024 and 5/2026

SAE International and UN Regulation for

ISO Standard for vehicle type approval
automotive cybersecurity and cybersecurity
engineering management systems
ISO 21434

UNECE WP.29 FAQS

.
Introduction
Which security is needed today

Source: www.electronicdesign.com

.
Terminology & Definition
Symmetric cryptography
 Each party knows one identical secret key
 Use case:
 UC1: Each party can encrypt & decrypt data

Key A Key A
Cryptography

Encryption Decryption

.
Terminology & Definition
Symmetric cryptography
 UC2: Each party can generate & verify authentication tags

Key A Key A

MAC MAC
OK
generation verification

NG

.
Terminology & Definition
Asymmetric cryptography
 Each party has two keys
 One private key (or secret key) which is kept strongly secret
 One public key, which is distributed open and everywhere
 Use case:
 UC1: Encrypt data with public key & decrypt data with private key

Public Key Private Key

Key pair
Generation

Encryption Decryption

.
Terminology & Definition
Asymmetric cryptography
 UC2: Generate signature with private key & verify signature with public key
 One way cryptography

Private key Public key

Key pair
Generation

Signature Signature
OK
Generation Verification

NG

.
Terminology & Definition
Symmetric cryptography vs Asymmetric cryptography

Source: www.thesslstore.com

.
Terminology & Definition The state-of-the-art requires measures to avoid known or reasonably
foreseeable risks based upon generally available, not necessarily new,
Security State-of-the-Art technical findings and solutions that recognized experts use. These measures
become state-of-the-art, as soon as they are a) scientifically proven (i.e., in
theory), b) available for series production, and c) practically useable.

For example, the compliance with legal requirements, technical regulations,

proven rules and procedures as well as pertinent textbook knowledge from the
Security Level

respective disciplines are counted among the state-of-the-art.

Low security risk - conformance

State-of-the-art
Product B Product D (as e.g. product liability demands)

Product A Product C Increase by e.g. higher

computing power

High security risk – non-conformance

2021 2022 2023 2024 2025 2026
Time
Increase by e.g.
new attack methods
or regulations
Source: BBM CS baseline

.
Terminology & Definition
HSM – Hardware Security Module

VS

Source: https://en.wikiarquitectura.com

.
Terminology & Definition
HSM – Hardware Security Module
Hardware-based
Roots of Trust

Adequate SW/HW security Co-Design

Dedicated execution environment for security critical functions
Protection of cryptographic materials and secrets with HW-measures to prevent extraction

.
Terminology & Definition
TARA (Threat and Risk Analysis)

ECU
(TOE)

.
Terminology & Definition
TARA (Threat and Risk Analysis)

Security Threat
Goals Modeling

ECU
(TOE)

.
Terminology & Definition
TARA (Threat and Risk Analysis)

Security Threat
Goals Modeling

ECU
(TOE)

Risk Risk
Handling Assessment

.
Terminology & Definition
TARA (Threat and Risk Analysis)

Security Threat
Goals Modeling

ECU
(TOE)

Risk Risk
Handling Assessment

Secure Secure Sec

Measure Feature concept

.
Security Features
Overview
1) Secure Access Secure Access for diagnosis and re-programming
2) Secure Lifecycle Enhance work efficiency during development, production…
3) Secure Flashing Firmware authentication via software signatures
4) Hardware Interface Protection Protect the JTAG port from unauthorized usage
5) Secure In-Vehicle Communication Authenticity and Integrity for internal communication
6) Trusted Boot Secure/Authentic hybrid boot sequence
7) Runtime Manipulation Detection Cyclic verification of code-flash authenticity
8) Secure Data Storage Ensure authenticity and confidentiality of stored data
9) Secure Logging Store and protect security related events
10) Secure Feature Activation Activate features only after authorization

.
Security Features
Secure Access
 Ensures only authorized parties can gain the access to ECU diagnosis services
 Apply symmetric or asymmetric cryptography
 May support several authorization levels to increase access control

.
Security Features
Secure Access (Symmetric Crypto.)
Tester/ ECU
FOTA master

Security access request

.
Security Features
Secure Access (Symmetric Crypto.)
Tester/ ECU Random
FOTA master value
generation
Security access request

Seed
Respond with Seed / Challenge Seed

Encryption Key B Encryption

Key A

.
Security Features
Secure Access (Symmetric Crypto.)
Tester/ ECU Random
FOTA master value
generation
Security access request

Seed
Respond with Seed / Challenge Seed

Encryption Key B Encryption

Key A
Send Key / Response Key A

.
Security Features
Secure Access (Symmetric Crypto.)
Tester/ ECU Random
FOTA master value
generation
Security access request

Seed
Respond with Seed / Challenge Seed

Encryption Key B Encryption

Key A
Send Key / Response Key A
Comparision

Respond with Result OK

Unlock
feature

.
Security Features
Private key Public key
Key pair
Generation

Secure Access (Asymmetric Crypto.) Signature

Generation
Signature
Verification

NG
OK

.
Security Features
Private key Public key
Key pair
Generation

Secure Access (Asymmetric Crypto.) Signature

Generation
Signature
Verification

NG
OK

.
Security Features
Private key Public key
Key pair
Generation

Secure Access (Asymmetric Crypto.) Signature

Generation
Signature
Verification

NG
OK

.
Security Features
Private key Public key
Key pair
Generation

Secure Access (Asymmetric Crypto.) Signature

Generation
Signature
Verification

NG
OK

.
Security Features
Private key Public key
Key pair
Generation

Secure Access (Asymmetric Crypto.) Signature

Generation
Signature
Verification

NG
OK

.
Security Feature
Secure Life Cycle
 Specifies a roles and authorizations model for usage in Secure Access
 Ensures access boundary for each life cycle

Plant

Access to all
Production features required
during production

Series
Access to only
(Mounted on
basic features
Vehicle)

.
Security Feature
Secure Life Cycle
 Specifies a roles and authorizations model for usage in Secure Access
 Ensures access boundary for each life cycle

Plant
Access to almost all features Access to features
(needs by developers) required for ECU test
Access to all
Development features required
Production
during production

Verification

Series
Access to only
(Mounted on
basic features
Return Analysis Vehicle)

All access required to analyze the ECU issue

.
 Private key Public key

Security Feature
Key pair
Generation

Secure Flashing Signature

Generation
Signature
Verification

NG
OK

 Ensure only authentic and non-manipulated firmware images can be flashed

 Firmware image includes cryptographic signatures for verification.

Code & Data hash

verify OK

passed
NG
Digital signature

Certificate
Pub key

.
Security Features
Hardware Interface Protection
 Disable or protect HW-I providing privileged access.
 Used uC must offer the adequate protection mechanisms
Data flow Data flow
in secure
channel

Factory Lock interface

Embedded Device
with secret

Tester
Generate Secret

Tester HSM

Database

Tester
Production
Key Server

.
 Key A Key A

Security Features
Secure Communication MAC
generation
MAC
verification

NG
OK

Message Authentication Codes

Assure authenticity and integrity of the data

sent using MACs calculated by the sender
and verified at the receiver based on
symmetric approach based on block
cipher (AES) and pre-shared keys.
(Truncated) MACs are transmitted along
with data.

.
Secure Coding
Example – Heartbleed Bug

pS

REQ Length Data SrcData

request
memcpy(pD, pS, Length)
mirrored response
RES Length Data DstData
user
server
pD

 void *memcpy(void *dest, const void *src, size_t n)

copies n characters from memory area src to memory area dest.

.
Secure Coding
Example – Heartbleed Bug

pS

65535
REQ 1 byte SrcData
bytes
request
memcpy(pD, pS, Length)
mirrored response
65535
RES 1 byte 65534 bytes DstData
bytes
user
server
pD

.
Secure Coding
Principle
 Easy to read int func(int x)
{
if (x++<x*++x);
return 1;
return 0;
}

Source: SPD training

.
Secure Coding
Principle
 Easy to read void func(void)
 Easy to understand {
int a=14, b=sizeof(a++);
printf(“%d, %d\n”, a, b);
}

Source: SPD training

.
Secure Coding
Principle
 Easy to read void Execute(Runnable action, int count)
 Easy to understand {
 Validate expectations towards input data for (int i=0; i<count; i++)
action.run();
}

Source: SPD training

.
Secure Coding
Principle
 Easy to read void func(char* in_string)
 Easy to understand {
 Validate expectations towards input data char *str =
 Checks for and handles errors (char*)malloc(strlen(in_string));
 Expects exceptional conditions strcpy(str, in_string);
}

Source: SPD training

.
Secure Coding
Principle
 Easy to read
 Easy to understand
 Validate expectations towards input data
 Checks for and handles errors
 Expects exceptional conditions
 Relies on specification guarantees and tests
 Do not rely on unspecified behavior
 Consider doing peer reviews
 Automate as much as possible
 Evaluate code analysis tools for your
code base

Source: SPD training

.
Secure Coding
Principle
 Easy to read
 Easy to understand
 Validate expectations towards input data
 Checks for and handles errors
 Expects exceptional conditions
 Relies on specification guarantees and tests
 And more…

Source: SPD training

.
Secure Coding
Principle
Example: Is there any wrong in following code? Expected output:
{ 0x1234
short int target;
char source[] = {0x12, 0x34};
memcpy((char*)&target, &source[0], 2);
return target;
}

.
Summary
Group Activities
 You are a new security engineer. Your first assignment is
designing the security features to protect a new electric car
with many modern features.

.
Appendix
Functional Safety vs Security
 Safety: focuses on risk resulting from random  Security: focuses on risk resulting from
failures, accidents and systematic failures during deliberate attacks carried out by intelligent
item development attackers
 Goal is to prevent the system from causing  Goal is to prevent people from causing intentional
unintended harm to people harm to the system

SECURITY SAFETY

Note: Security issue or solution may compromise safety. E.g.: RAM test, CRC vs CMAC.

.
Thank you!

96