Verification of IVI Over-The-Air using UML/OCL @ ICCC 2019 (International Common Criteria Conference), which is a major conference for the community of experts involved in security evaluation

1. Security Analysis aNd Evaluation Lab.
ICCC 2019
2019. 10. 01
Verification of IVI Over-The-Air
using UML/OCL
Sooyoung Kang* Seungjoo Kim**
bbang814@gmail.com* skim71@korea.ac.kr**
*1st Author
CIST (Center for Information
Security Technologies),
Korea University
**Corresponding Author
CIST (Center for Information
Security Technologies),
Korea University

2. 2 / 33
Contents
1. Introduction
2. Motivation
3. Assurance Level for OTA
4. Targeting Architecture for OTA
5. Modeling
6. Specification and Verification
7. Conclusions & Future works

3. 3 / 33
1. Introduction
▪ Automotive Cybersecurity Market
▪ Research institute named “Grand View Research” expects
that market for global automotive cybersecurity will increase
up to USD 5.77 billion by 2025 from USD 1.34 billion in 2018
▪ Automotive cybersecurity become more and more important,
and infotainment market is the largest among them
2018 2019 2020 2021 2022 2023 2024 2025
Infotainment ADAS & Safety System PowerTrain Body Electronics Telematics
USD 1.34 billion
USD 5.77 billion

4. 4 / 33
1. Introduction
▪ Infotainment
Information Entertainment

5. 5 / 33
1. Introduction
▪ Hacking Case
• Jeep Cherokee hacking(2015)
• Blackhat USA 2015, “Remote exploitation of
an unaltered passenger vehicle”,
Charlie Miller, Chris Valasek
• Acquiring root privilege by accessing Jeep
Cherokee infotainment Uconnect remotely
• Tesla hacking(2016)
• Blackhat USA 2016, “Hacking Tesla from
Wireless to CAN Bus”, KEEN Security Lab
• Acquiring root privilege by injecting
malware through Wi-Fi hotspot in Tesla
infotainment

6. 6 / 33
1. Introduction
▪ OTA(Over-The-Air)
▪ Secure and efficient software or firmware update
technology using wireless
▪ Used to patch up system components in the vehicle
for fault diagnostics
User
Infotainment
ECU
ECU
ECU
Administrator
(Driver) S/W
S/W
S/W
S/W
OEM Server
OEM Server
EUC Software
Developer
S/W
F/W
Vehicle Info.
PW(Nonce)
User Info.
Key
IVI Firmware
Developer
F/W
F/W
F/W
F/W
SOTA: Software Over-The-Air FOTA: Firmware-Over-The-Air

7. 7 / 33
2. Motivation
▪ Automotive SSDLC
▪ UNECE will announce cybersecurity regulations in
September 2020 and allow to export only automotive
that comply with them from 2022
▪ Also UNECE regulates SSDLC comply with cybersecurity
by integrating into the lifecycle of automotive
* UNECE: United Nations Economic Commission for Europe
* SSDLC(Secure Software Development LifeCycle)

8. 8 / 33
2. Motivation
▪ Automotive SSDLC
▪ SSDLC(Secure Software Development LifeCycle)
▪ The process which checks product status at security
view in every stage of the SDLC to develop software
securely
Training Design Release
Establish
Security
Requirements
Create
Quality Gates/
Bug Bars
Security &
Privacy Risk
Assessment
Core Security
Training
Establish
Design
Requirements
Analyze Attack
Surface
Threat
Modeling
Use Approved
Tools
Deprecate
Unsafe
Functions
Static Analysis
Dynamic
analysis
Fuzz Testing
Attack Surface
Review
Incident
Response Plan
Final Security
Review
Release
Archive
Execute
Incident
Response Plan
Requirements Implementation Verification Response
Repeat
* SDLC: Software Development LifeCycle

9. 9 / 33
2. Motivation
▪ Automotive SSDLC
▪ Advantage of SSDLC
▪ In security view, the number of vulnerabilities found in
software reduced after release
▪ Also a lot of costs are saved through patch for vulnerabilities
0
20
40
60
80
100
120
140
Windows XP
(SDLC)
Windows Vista
(SDL)
119
66
45%
▪ Shift Left: Security which is done in end of process is considered in initial stage of development
▪ Continuous Improvement: Security of software enhanced by repeating SSDLC
Needs for Shift Left & Continuous Improvement strategy

10. 10 / 33
2. Motivation
▪ Automotive Cybersecurity
▪ The GRVA division under UNECE is in the process of
developing regulation on Cybersecurity and Over-The-Air
Cybersecurity Over-The-Air
Threat analysis
Data protection
security aspects
Security
aspects
Certification
aspects
Safe
execution
Pre-
registration
Post-
registration
Develop flow
diagram
Define approval
method
Develop Recommendation
on Cybersecurity
Develop Recommendation
on Software update
Define mitigation
principles
Develop
recommendation
for safe
execution

11. 11 / 33
2. Motivation
▪ Automotive Cybersecurity
▪ In ISO/SAE 21434, 4 PGs are created and currently
underway in standardizing cybersecurity of automotive
▪ Among them, PG1 is in the process of standardizing CAL
which is achieved in automotive
▪ Unlike past both security and safety are important in
automotive
PG1: Risk
Management
PG2: Product
Development
PG3: Production,
Operation &
Maintenance
PG4: Process
Overview and
Interdependences
OEMs
Ford, GM, Volvo, Mitsubishi, FCA, Honda,
Toyota, Volkswagen, BMW, Jaguar-Land
Rover, Opel, Peugeot, Renault, Daimler,
Nissan, Iveco, etc.
RESEARCH/ VALIDATION
University of Warwick, Southwest
Research Institute, AIT, Horiba
Mira, UL, TUV, Bureau Veritas, etc.
CYBERSECURITY
COMPANIES
Karamba, Vector, TowerSec,
Synopsys, etc.
ECU SUPPLIERS
Continental, Valeo, Bosch, Lear, Delphi, ZF,
Magna, Denso, Hella, Wabco, Actia, etc.
GOVERNING ORGANIZATION
NIST, RDW, etc.
MICRO SUPPLIERS
Infineon, Intel, Melexes,
ON Semiconductor, etc.
STANDARDS ORGANIZATION
SAE, ISO, JSAE, VDA, etc.
OTHERS
STEER, Thales, Method Park,
BNA, Scania, etc.
PG1 co-worked with 82 major organization
* PG(Project Group)
* CAL(Cybersecurity Assurance Level)

12. 12 / 33
3. Assurance Level for OTA
▪ Automotive Assurance Level
▪ According to the ITS book published by WILEY,
automotive safety level is mapped into EAL
▪ Infotainment has to achieve ASIL C or higher
▪ Infotainment related to entertainment should achieve ASIL B
▪ Infotainment related to gateway should achieve ASIL D
▪ Risk Level
IEC 61508 ISO 26262 ISO/IEC15408
SIL ASIL EAL
Low level 1 A 1
Low level 1 A 2
Medium Level 2 B 3
Medium Level 2 B 4
High Level 3 C 5
High Level 3 D 6
High Level 4 Not applicable 7

13. 13 / 33
3. Assurance Level for OTA
▪ Automotive Assurance Level
Assurance
Class
EAL5 EAL6 EAL7
ADV(6)
ADV_ARC.1 ADV_ARC.1 ADV_ARC.1
ADV_FSP.5 ADV_FSP.5 ADV_FSP.6
ADV_IMP.1 ADV_IMP.2 ADV_IMP.2
ADV_INT.2 ADV_INT.2 ADV_INT.2
ㅡ ADV_SPM.1 ADV_SPM.1
ADV_TDS.4 ADV_TDS.5 ADV_TDS.6
AGD(2)
AGD_OPE.1 AGD_OPE.1 AGD_OPE.1
AGD_PRE.1 AGD_PRE.1 AGD_PRE.1
ALC(6)
ALC_CMC.4 ALC_CMC.5 ALC_CMC.5
ALC_CMS.5 ALC_CMS.5 ALC_CMS.5
ALC_DEL.1 ALC_DEL.1 ALC_DEL.1
ALC_DVS.1 ALC_DVS.2 ALC_DVS.2
ALC_LCD.1 ALC_LCD.1 ALC_LCD.2
ALC_TAT.2 ALC_TAT.3 ALC_TAT.3
ASE(7)
ASE_CCL.1 ASE_CCL.1 ASE_CCL.1
ASE_ECD.1 ASE_ECD.1 ASE_ECD.1
ASE_INT.1 ASE_INT.1 ASE_INT.1
ASE_OBJ.2 ASE_OBJ.2 ASE_OBJ.2
ASE_REQ.2 ASE_REQ.2 ASE_REQ.2
ASE_SPD.1 ASE_SPD.1 ASE_SPD.1
ASE_TSS.1 ASE_TSS.1 ASE_TSS.1
ATE(4)
ATE_COV.2 ATE_COV.3 ATE_COV.3
ATE_DPT.3 ATE_DPT.3 ATE_DPT.4
ATE_FUN.1 ATE_FUN.2 ATE_FUN.2
ATE_IND.2 ATE_IND.2 ATE_IND.3
AVA(1) AVA_VAN.4 AVA_VAN.5 AVA_VAN.5

14. 14 / 33
3. Assurance Level for OTA
Requirements Design
Verification
Release
Response
ASE ADV ADV ATE/AVA ATE/AVA
ASE_CCL
ASE_ECD
ASE_INT
ASE_OBJ
ASE_REQ
ASE_SPD
ASE_TSS
ADV_IMPADV_ARC
ADV_FSP
ADV_INT
ADV_SPM
ADV_TDS
ATE_COV
ATE_DPT
ATE_FUN
ATE_IND
AVA_VAN
ATE_COV
ATE_DPT
ATE_FUN
ATE_IND
AVA_VAN
Threat
modeling
Static
analysis
Risk
analysis
Dynamic
analysis
Patch
Secure
Update
Modeling
(Semi)
Formal
Specification
and
verification
Pen
testing
Fuzzing
Implementation
High Level Over-The-Air

15. 15 / 33
4. Targeting Architecture for OTA
▪ Survey on Standards
▪ International standard
▪ ITU-T: SOTA(Software Over-The-Air), FOTA(Firmware-Over-The-Air)
▪ ISO TC22: Road vehicles(Vehicle Diagnostics, In-Vehicle Data Buses,
Network Applications, Test Equipment, Extended Vehicle)
▪ ISO TC204: Intelligent Transport Systems
▪ IEEE: V2X Communication for ITS
▪ ETSI: European Standards for Intelligent Transport Systems
▪ 3GPP: Cellular V2X
▪ Industry Consortium
▪ GENIVI Alliance: Infotainment Platform
▪ AUTOSAR: ECU Middleware Platform
▪ CAMP: Vehicular PKI, V2X Standard
▪ CAR2CAR: In-Vehicle Security and Trust Assurance Level

16. 16 / 33
4. Targeting Architecture for OTA
▪ Survey on Industry
Product Name
Development
Company
Country Description
GENIVI GENIVI Alliance
Standardization
Organization
Headquartered in
America
Opensource-based automotive platform
standardization
AGL
(Automotive Grade Linux)
AGL Alliance
Standardization
Organization
Headquartered in Japan
Linux-based automotive platform
standardization
Android Auto Google America Mobile device and mobile platform
CarPlay Apple America Mobile device and mobile platform
Windows in the Car Microsoft America Automotive platform operating system
QNX Blackberry Canada Mobile device and mobile platform
Tizen
Samsung
Electronics
/Intel
Korea
/America
Open source joint development with
AGL and GENIVI

17. 17 / 33
4. Targeting Architecture for OTA
▪ Survey on OTA Architecture
▪ OTA Architecture 1
App Store Server OEM Server
User
Infotainment
ECU
ECU
ECU
Smartphone/Storage
Administrator
(Driver)
App Store Server OEM Server
EUC Software
Developer
App
S/W
App
F/W
S/W
S/W
S/W
App Developer
App
App
App
Developer
IVI Firmware
Developer
User
Management
Vehicle
Management
Sign
verification
App
Management
Sign
verification
App
S/W
F/W
Vehicle Info.
PW(Nonce)
User Info.
Key
F/W
TOYOTA, BMW, AUDI,
MERCEDES-BENZ, Jeep,
LAND ROVER, CHEVROLET,
VOLKSWAGEN, FORD etc.
S/W

18. 18 / 33
4. Targeting Architecture for OTA
▪ Survey on OTA Architecture
▪ OTA Architecture 2
HYUNDAI Automotive
KIA Automotive
App Store Server OEM Server
User
Infotainment
ECU
ECU
ECU
Smartphone/Storage
Administrator
(Driver)
App Store Server OEM Server
EUC Software
Developer
App
S/W
App
F/W
S/W
S/W
S/W
App Developer
App
App
App
Developer
IVI Firmware
Developer
Sign
verification
App
Management
App/S/W/F/W
Management
Sign
verification
User
Management
Vehicle
Management
Sign
verification
App
S/W
F/W
F/W
S/W

19. 19 / 33
4. Targeting Architecture for OTA
▪ Survey on OTA Architecture
▪ OTA Architecture 3
Only TESLA
OEM Server
User
Infotainment
ECU
ECU
ECU
Administrator
(Driver)
OEM Server
EUC Software
Developer
S/W
F/W
F/W
S/W
S/W
S/W
Vehicle Info.
PW(Nonce)
User Info.
Key
IVI Firmware
Developer
S/W

20. 20 / 33
4. Targeting Architecture for OTA
▪ GENIVI Infotainment Platform
OEM Infotainment Application
OS
Remote
control
OTA
Architec
ture
GENIVI
platform
And
roid
iOS
1 Toyota Entune Entune app O O O
USB/
Infotainment 1
2 BMW iDrive My BMW Remote O O O
USB/
Infotainment 1 O
3
Mercedes
-Benz
MBUX
(Mercedes-Benz
Infotainment
System)
COMAND Touch
by Mercedes-Benz
O O O
USB/
Infotainment 1
4 Audi Audi MMI Audi MMI Connect app O O O
USB/
Infotainment 1
5 Land Rover Rand Rover
Land Rover InControl Remot
e
O O O
USB/
Infotainment 1 O
6 Tesla Tesla Tesla app O O O Infotainment 3
7 Chevrolet Mylink myChevrolet app O O O
USB/
Infotainment 1 O
8 Jeep Uconnect Uconnect app O O O
USB/
Infotainment 1
9 Volkswagen Volkswagen MySmart app O O O
USB/
Infotainment 1 O
10 Ford SYNC3 Ford Play O O O
USB/
Infotainment 1
11 HYUNDAI Blue Link Hyundai Smart Remote O O O
USB/
Infotainment 1 or 2 O
12 KIA UVO Remote Assistant O O O
USB/
Infotainment 1 or 2 O

21. 21 / 33
4. Targeting Architecture for OTA
▪ Target OTA Verification Process
Targeting Modeling
Semi-formal
Specification &
Verification
GENIVI OTA
source code
analysis
Class diagram
Validation result
Constraint
Specification Verification
Core function
Core
functionality
Core module
Constraint
specification
from source code
Check the
contradiction
in constraint
specification
Source code
abstraction
to UML
Source code

22. 22 / 33
5. Modeling
▪ Comparison & Analysis among Languages
UML
(Unified Modeling
Language)
Behavior Tree
ORM
(Object-Role
Modeling)
Petri net
Target Universal Requirement Data Behavior
Format Diagram Tree Diagram Diagram
Platform Open source Open source
Open source +
Commercial
Open source
Compatible
Language
Object-Oriented
Language
(Python, Java, Scala,
Rust etc.)
N/A
Database language
(Oracle, MySQL, MS
SQL etc.)
Formal language
(Isabelle/HOL, Z,
Timed-Automata
etc.)
Developer
Object Management
Group
(OMG)
R. Geoff Dromey
Control Data
Corporation
Research
Laboratory in
Belgium
Carl Adam Petri
Year 1990 2001 1970 1939

23. 23 / 33
5. Modeling
▪ UML(Unified Modeling Language)
▪ Class diagram
▪ Types of relationships
Item
+ price: long
- name: String
+ setName( )
+ getName( )
Class name
Attribute
Operation Constraint
Constraints
+ : public
- : private
Relationship Description Mark
Generalization
Inheritance
Relationship between parent class and child class
Association Relationship referencing class object
Aggregation Relationship between lifecycle-independent classes
Composition Relationship between lifecycle-dependent classes

24. 24 / 33
5. Modeling
▪ OTA Architecture Target
RVI
(Remote Vehicle Interaction)
Package
Manager
Module
Loader
OTA
Client
SW Loading
Manager
ECU
ECU
ECU
ECU
RVI
(Remote Vehicle Interaction)
Device
Registry
External
Resolver
Admin HMI
OTA
Server
WiFi/3G/LTE
BT/BLE/SMS
Core modules Core Functionality
SW Loading Manager
Display version notification
Request package download
Display package processing results
Package Manager [Package] Install, Update, Delete
Partition Manager [Partition] Create, Initialize, Assign, Resize, Delete
Module Loader Deliver and load packages to external modules
OEM Server Infotainment
Partition
Manager

25. 25 / 33
5. Modeling
▪ Modeling with UML
OTA Server side OTA Client side Hierarchy structure
Tool box
Relationship
Constraint
Result

26. 26 / 33
Service Loading
Manager Service Demon
Partition Manager
Service Demon
Package Manager
Service Demon
Service Demon that
delivers patches to
external sensors
5. Modeling
▪ Modeling with UML – OTA Infotainment side
Client Service
SW Loading Manager
Service
Partition Manager
Service
Package Manager
Service
Service that delivers
patches to external sensors
dbus Service

27. 27 / 33
6. Specification and Verification
▪ OCL(Object Constraint Language)
▪ A language that specifies the constraints of UML supported by IBM,
Microsoft, Oracle, HP etc.
▪ Specification using invariant, precondition, and postcondition settings
▪ Invariant: A condition that must always be established in a class
▪ Precondition: A condition that must be established before class processing
▪ Postcondition: A condition that must be established after class processing
▪ Operators
▪ +, ㅡ, *, /
▪ not, and, or, xor, implies
▪ <, >, <=, >=
▪ =
▪ if a then b else c endif

28. 28 / 33
6. Specification and Verification
▪ Specification and Verification with OCL
▪ Core functionality and function examples
Notify
Download
Retry
Validate
Install
Check whether a patch package can be installed
Perform initialization to install patch packages
Start and complete package download
Resend when patch package download fails
Check patch package integrity
digital sign verification
Receive and install patch package
from Software Loading Manager
Remove Delete a patch package
updateAvailable( )
getPackageVersion( )
initiate_download( )
get_installedPackages( )
retryPackage( )
checkinstalledPackage( )
installPackage( )
removePackage( )
Core Functionality Core Function

29. 29 / 33
6. Specification and Verification
▪ OCL Examples
▪ Evaluates
▪ True = silent, invariant is satisfied
▪ False = invariant is not satisfied / evaluates ‘no initial state’(warning)
▪ Null = invariant is not satisfied / evaluates ‘no initial state’(error)
▪ Invalid = exception, evaluation failure
Context InstallState
inv: self.packgeVersion -> forAll(v.current_version < v.new_version)
inv: self.Partition -> forAll(s.partition_size > s.downloadpackage_size)
inv: self.PackageSign -> forAll(result = True(silent, invariant is satisfied)
‘InstallState’ constraint definition
Current version must be smaller than new version
Partition size must be larger than package file size
context PackageSignVerif
def: algorithm = self.ECDSA
context package
inv: self.PackageSignVerif =True(silent, invariant is satisfied)
post: state = install
‘PackageSignVerif’ constraint definition
Digital signature algorithm is defined as ECDSA 256bit or higher
‘Package’ constraint definition
Package digital signature verification result must ‘True’
Must install after digital signature verification
Result
Package digital signature verification must complete

30. 30 / 33
6. Specification and Verification
▪ Coverage of OCL Verification
Core
module
Core
functionality
Core
function
Verification
Completion
SW Loading
Manager
Notify
updateAvailable( )
getPackageVersion( )
5/12
Download
initiate_download( )
get_installedPackages( )
Retry retryPackage( )
Package
Manager
Validate checkinstalledPackage( )
3/7Install installPackage( )
Remove removePackage( )
Partition
Manager
Download
initiate_download( )
get_installedPackages( )
4/5
Install installPackage( )
Remove removePackage( )
Module Loader Notify
updateAvailable( )
getPackageVersion( )
2/3
51% 49%
Over-The-Air
IncompletionCompletion
Infotainment
Take about 1 year
Automotive

31. 31 / 33
7. Conclusions & Future works
▪ Conclusions
▪ Cybersecurity and OTA are the most important factor
▪ Infotainment served as gateway should achieve high
assurance level
▪ To verify that OTA source code is no logical contradiction with
UML/OCL semi-formally
▪ Verification completed for approximately 51% of source code
▪ Take about a year to utilize opensource, but take much more
time without source code
▪ The verification for 49% and EAL6 or higher in the future
▪ Can be utilized when high assurance system achieve CC
certificate

32. 32 / 33
7. Conclusions & Future works
▪ Future works
▪ High assurance software systems are becoming more complex
▪ Monolithic evaluation methods, such as CC, have exponential growth in
evaluation effort as complexity of TOE increases
▪ As complexity increases, study on composition evaluation methods is
required
▪ The existing composite package, CAP, is below EAL4
▪ We will study on CPE, a composition package of EAL5 or higher
Certified Base TOE
Certified Dependent
TOE
Composed TOE
Provide
resource,
service
Certified Platform
Uncertified Application
Composed TOE
Provide
resource,
service
Manage
security
functions
CAP
(Composed
Assurance
Package)
CPE
(Composite
Product
Evaluation)

33. 33 / 33
Thank you
bbang814@gmail.com, skim71@korea.ac.kr
This work was supported by Institute for Information & communications Technology Promotion(IITP) grant funded by the Korea government
(MSIP)(IITP-2017-0-00184, Self-Learning Cyber Immune Technology Development)
This research was supported by the MSIT(Ministry of Science and ICT), Korea, under the ITRC(Information Technology Research Center) support
program(IITP-2019-2015-0-00403) supervised by the IITP(Institute for Information & communications Technology Planning & Evaluation)