EMBEDDED

SAFETY &
SECURITY
[email protected]

TUAN HOANG , L10 OF ES COURSE, 2023

 LOOK BACK

We have various requirements from point of:

Meeting all
requirements High customer satisfaction

Not meeting
Requirements 2
Low customer satisfaction
EXAMPLE

3
WHAT IS A SYSTEM SAFETY?
Safety is a concept that includes all measures and practices
taken to preserve the life, health, and bodily integrity of
individuals
Safety Culture in Product development is the way safety is
perceived, valued and prioritized in each of stage of Product
Development Life Cycle

4
WHAT IS A SYSTEM SAFETY?
System safety is a specialty within system engineering that supports program risk
management that optimizes safety.
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

5
IS YOUR SYSTEM APPROPRIATELY SAFE?
Anti-Patterns for Embedded System Safety:
• Requirements do not address safety
• Not using an appropriate safety standard
• Safety analysis assumes perfect software
• Redundancy management inadequate

Know system is safe:

• Correctness is only a starting point:
- Requirements and other aspects matter
• Fault responses must be safe
- Hardware faults (permanent; transient)
- Software faults

6
DEFENSE-IN-DEPTH FOR SAFETY
 Avoid faults occurring:
- Careful design of software to avoid software defects
- Use robust hardware to avoid hardware run-time faults
 Detect and contain faults:
- Error correction HW, redundant CPUs
- Watchdog timers for failed tasks, exception handling
 Use Fail Safe strategies to mitigate hazards:
-For example, automatic safety shutdown mechanisms
 Incidents require operator intervention (or luck)
- Operator may be able to react correctly and quickly
- Incident will be a mishap some fraction of time
 Want to avoid escalation as much as possible
- E.g., fail safe approaches that work to avoid incidents
7
BASIC SAFETY PRINCIPLES
• Safety must be seen to be present:
- System presumed unsafe unless convincing safety argument made
- Outsider must be able to determine safety purely from documents
• The greater the risk, the greater the need for information:
- Riskier systems require more engineering rigor

• Safety must be built in, not added on:

- If code is created without a safety process, throw it away; start over
• Systematic, random, and malicious faults all matter
- Consider design errors and transient faults (e.g., soft errors)
- If it’s not secure, it’s not safe
• Safety must be argued in writing and demonstrated:
- Failure-free testing isn’t enough

• Safety is a lifecycle concern:

- “Mission critical failures” can be considered “safety” as well
8
FUNCTIONAL SAFETY
& ISO 26262 STANDARD
At its simplest functional safety is the part of the
overall safety relating to the equipment under
control and its associated control system that
depends on the correct functioning of the safety-
related system
IEC 61508 — The Umbrella Standard

IEC 61508 and related standards (e.g., IEC 61511 and IEC 62061) as the benchmark for
achieving functional safety and manage risks in a proportionate way
• Is a subset of Product Safety
• For the consumer, it implies:
 The product operates correctly in response to inputs
 It poses no unacceptable risks even in failure conditions
9
ISO 2626 & ISO 61508

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

10
IEC 61508 AND SAFETY INTEGRITY LEVEL (SIL)
IEC 61508 is an international functional safety standard, and it provides a framework for
safety lifecycle activities. Titled “Functional Safety of Electrical/Electronic/Programmable
Electronic Safety-related Systems (E/E/PE, or E/E/PES)”, 61508 is the umbrella functional
safety standard — and the source for industry-specific standards.

The standard covers safety-related systems that incorporate electrical/electronic

/programmable electronic devices. The standard specifically covers hazards that occur
when safety functions fail. And the main goal of the safety standard is to reduce the risk
of failure to a tolerable level.

The standard helps determine Safety Integrity Levels (SIL). There are four SILs: SIL1, SIL2,
SIL3 and SIL4, the risk of failure becoming greater with each respective SIL

11
SIL
Probability of
Safety Integrity Risk Reduction
Failure on
Level Factor
Demand
100,000 to
SIL 4 ≥105 to <104
10,000
SIL 3 ≥104 to <103 10,000 to 1,000
SIL 2 ≥103 to <102 1,000 to 100
SIL 1 ≥102 to <101 100 to 10
Functional
Safety Safety Levels (Least to Most Stringent)
SIL= Safety Integrity Level Standard
SIL4 = catastrophic IEC 61508 - SIL 1 SIL 2 SIL 3 Sil 4
SIL1 = minor injuries ISO 26262 ASIL A ASIL B ASIL C ASIL D -
Used to determine required level
DO-178C Level E Level D Level C Level B Level A
of engineering rigor
IEC 62304 Class A Class B Class C
EN 50128 SSIL 0 SSIL 1 SSIL 2 SSIL 3 SSIL 4
12
GUIDE TO IEC 61508 SOFTWARE COMPLIANCE
Complying with the safety standard — or its industry-specific variants — is important for all safety-critical developers.
And it’s crucial to maintain compliance throughout the safety lifecycle of your products.
You’ll need to use specific methods (based on SILs) from the standard to avoid mistakes and errors throughout the
lifecycle. But this can be difficult to enforce

Establish Requirements Traceability : Apply a Coding Standard:

Fulfilling functional safety requirements — and Ensuring safe, secure, and reliable code can be difficult. Your
proving you’ve met them — is a challenge. code needs to fulfill specific design and coding guidelines
Requirements need to be carried through into based on SIL ratings.
architecture, design, and coding. Testing needs to Applying a coding standard (e.g., MISRA) makes it easier to
verify that requirements are fulfilled every step of verify your code against specific safety standard guidelines.
the way. Only then can you validate the software Especially when you use a static analysis tool, such as Helix
meets the requirements of the safety standard. QAC or Klocwork .

13
MOTIVATIONS: MALFUNCTION AND ITS IMPACTS
We do not want to be in the media with comparable headlines

14
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

15
 APPROACHES TO ISO 26262

always
always

Initial risk level Risk reduction due to

E*C=1 QM* B C D before development external measures e.g
phase Controllability by the
driver
E*C=0,1 QM* A B C

Frequency
Automotive Safety
Frequency

ASIL Integrity Level

E*C=0,01 QM* QM A B (i.e. necessary risk
reduction)

E*C=0,001 QM* QM QM A
Achieved risk level Reasonable
E*C=0,0001 QM* QM QM QM at release for Residual Risk
production
remote

Probability of Exposure
remote

E*C=0,00001 QM* QM QM QM to driving situation

S0 S1 S2 S3
negligible Severity catastrophic Severity of possible accident
negligible Severity catastrophic

16
 SECURITY
• What Is Embedded Systems Security?

Embedded systems security is a design

methodology, implementation, and
commitment that companies embrace to
limit the threat exposure of the devices
they build and the data these devices
generate. Security for embedded devices is
a full lifecycle responsibility. It starts well
before the first line of code is written,
includes protection in case a device falls
into the hands of attackers, and continues
until a device has been decommissioned.

IDC estimates that by 2025, there will be more

than 55 billion connected devices

17
 THE CIA TRIAD AND HOW IT CONTRIBUTES TO AN
EMBEDDED SECURITY POLICY
Similar to IT systems, an embedded
security policy uses the CIA triad as a
model for policy development. The
CIA triad defines the principles
needed to protect a device from
unauthorized access, use, disclosure,
disruption, modification, or
destruction. This model helps
development teams think about the
different aspects of security for their
project. The CIA acronym stands for
confidentiality, integrity, and
availability.
18
INTEGRITY
Confidentiality implementations are used to protect the privacy of data in embedded
systems. This includes data in motion, data at rest or stored on the device, data being
processed by the device, and data passing to and from the device.

CONFIDENTIALITY
Integrity implementations ensure that the embedded device data has not been modified
or deleted by an attacker. This includes data being generated or consumed by the
embedded device as well as its programming data (the operating system, applications,
configurations data, etc.).

AVAILABILITY
Availability implementations ensure that an embedded device performs its intended
function. This means an attacker cannot change a device’s intended functional purpose.
This is of paramount importance to devices that perform life- or mission-critical tasks.
19
 THE DIFFERENCE BETWEEN EMBEDDED SECURITY AND
CYBERSECURITY
• Embedded security is designed to protect the components and software
of the device. It includes features to protect the hardware, operating
system, application, and data.
• Cybersecurity refers to additional security features that protect a device
from network-initiated attacks.
• Both forms of security are necessary for embedded systems, IoT
products, and intelligent edge devices.
• Both embedded security and cybersecurity are necessary for reliable
embedded device performance across a range of industries.

20
WHAT IS CYBER SECURITY IN AUTOMOTIVE
COSIC researchers hack Tesla Model X key fob
• Technologies, processes, and practices designed
to protect
networks, devices, programs, and data
from attack, damage, or unauthorized access.

21
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
•… ☛ The effort was too high compared to the benefit.

22
WHY DO WE NEED CYBER SECURITY TODAY

Source: www.microcontrollertips.com
23
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...)
24
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 ISO UN Regulation for vehicle type

Standard for automotive approval and cybersecurity
cybersecurity engineering management systems

ISO 21434

UNECE WP.29 FAQS

25
HSM – HARDWARE SECURITY MODULE

26
HSM – HARDWARE SECURITY MODULE

• 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
27
FUNCTIONAL SAFETY VS SECURITY
• Safety: focuses on risk resulting from random • Security: focuses on risk resulting from deliberate
failures, accidents and systematic failures during attacks carried out by intelligent attackers
item development • Goal is to prevent people from causing intentional
• Goal is to prevent the system from causing harm to the system
unintended harm to people

SECURITY SAFETY

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

28
THANK YOU
FOR YOUR
INTEREST!
EMBEDDED SAFETY & SECURITY
REFERENCE
https://en.wikipedia.org/wiki/System_safety
https://www.windriver.com/solutions/learning/embedded-systems-security
https://medium.com/a4bee/best-practices-for-embedded-system-security-1da64390a9a1
https://www.qt.io/embedded-development-talk/how-to-use-the-best-security-for-your-
embedded-system
https://www.securecodewarrior.com/article/embedded-systems-security
http://www.differencebetween.net/language/words-language/difference-between-safety-
and-security/

30
Is my embedded design secure?
A determination of whether your embedded devices are secure is based on the technology used and the
operational environment. The security assessment identifies the assets of the system, the vulnerabilities of
and threats to those systems, and the mitigations required to protect the assets from the vulnerabilities.

How much security is enough?

Security requirements for embedded systems differ based on operational functionality and
risk tolerance. If a device performs a mission- or safety-critical function, security
requirements will be more comprehensive. Even if a device puts no human in harm’s way,
it might be able to be hacked for data or manipulation. Every embedded project should
have a security assessment and plan.

How do I use security features of the hardware and software to secure a device?
Often, the security features built in to the hardware require a software function in the operating system for
enablement. Secure boot and accelerated crypto-processing are two examples. A security assessment and plan
before a project starts can help determine which features from the hardware you want to activate. The operating
system and support for hardware security drivers can be required.

31
FUTURE OF EMBEDDED SECURITY
A lot of work is being done in the embedded security market. Experts believe that the market’s compound annual
growth rate (CAGR) can reach a figure of 5.5% during the 2021-2026 period. With more and more IoT devices being
launched, we can expect new embedded security standards to get established.

The increasing adoption of wearable medical devices is also going to increase the demand for dependable embedded
security solutions. For devices to contain and process sensitive medical data, they need to pass certain security
checklists, and we hope that’s going to make vendors and engineers focus on security more.

In the future, we may also have solutions that allow for remote visibility, monitoring, and control of the main software
and hardware components in embedded devices. This will truly be a game-changer in the world of embedded system
security.

At the end of the day, digital signatures, encrypting data, adding firewalls, implementing access control, and
randomizing operations can only take you so far. To build truly secure devices, developers need to be trained to write
secure code. Identifying potential security risks, and mitigating them during the application design phase, goes a long
way in making systems intrinsically secure.

32