Initial Issue Date：2015/3/31
Revised Date：2018/2/2 *1
ECSEC.TRA
Guidance

Introduction
This document is the guidance for the data base (the DB, hereafter) which handles data forthreats/vulnerabilities of HW (hardware) security, security objectives and public papers
concerned with those technical areas. The development of the guidance wasaccomplished based on the business plan, which was the cyber security economy
infrastructure construction project (vulnerability analysis techniques for hardware) ofMinistry of Economy, Trade and Industry, 2014 and was undertaken by Electronic
Commerce Security Technology Research Association.

1. Target audience of the guidance
It is intended that the target audience of the guidance and the DB is the groups shown
below:

Users of embedded devices



Developers of embedded devices



Developers of parts for embedded devices



Developers of semiconductor chips

Persons concerned with security evaluation and certification

Persons concerned with information security research

2. The definition of information processing functionalities covered by the guidance
The guidance defines the information processing functionalities in information security asfollows.
HW (System LSIs put in embedded devices or parts of embedded devices) and SW(OS + applications) installed in the HWThey do not rely on any versatile OSs



Some security functionalities such as cryptographic operational functions dependon the HW (e.g. HW cryptographic libraries are implemented)

3. The scope of attacks
In the document, the attacks concerned with information security are defined asfollows.
The attacks involving HW parts of information processing functionalities definedin the second chapter. That is to say, the attacks limited to SW parts are excluded.
1The attacks are limited to direct accessing for objects. That is, SW attacks via
logical interfaces (likely from remote) are excluded.

4. The attack patterns
In the document, the attack patterns concerned with information security are defined asfollows.
4.1

Physical Attacks

4.2

Overcoming sensors and filters

4.3

Perturbation Attacks

4.4

Retrieving keys with DFA

4.5

Side-channel Attacks — Non-invasive retrieving of secret data

4.6

Exploitation of Test features

4.7

Attacks on RNG

4.8

Ill-formed Java Card applications

4.9

Software Attacks

4.10

Applet isolation4.12

Physical Uniclonable Function*1

4.13

Machine Learning*1

4.15

Hardware Trojan*1
The above are quoted from <CC Supporting document/Mandatory TechnicalDocument “Application of Attack Potential to Smartcards” May 2013 Version 2.9
CCDB-2013-05-002 >.
Note that most attack patterns of 4.8 – 4.10 are out of the scope of attacks
provided in the third chapter.

In the DB, if a type of attack described in a paper comes under a pattern sorted above, thepaper will be categorized with the attack pattern numbers. (An attack pattern number isshown by numerical figures after a decimal point of the section numbers above; e.g.
“4.10” → “10”)The DB provides the feature retrieving papers relevant to each attack pattern.
If a paper corresponds to a specific attack pattern, the DB will also provide explanation of
the attack pattern and examples of well-known countermeasures for the attack in thedetail information column for the respective paper. However, the DB does not necessary
provide definite countermeasures for the attacks described in respective papers.
English part of the description in the DB above was quoted from CCDB-2013-05-002,
Mandatory Technical Document, Application of Attack Potential to Smartcards, except
well-known countermeasures.
Although Japanese part of the description above was quoted from the translated version
of CCDB-2013-05-002 by IPA, the underlined part was translated based on discussions
by this association. Further, the CC supporting document did not include “well-known2

countermeasures”. They were described originally by this association.
*1 In FY 2017, three types of attack types were added.This is because new attack types thatcan not be classified into 1 to 10 are added in this paper addition.

5. Classification of papers
In the DB, every paper is classified with the class number below.
Attacks for HW, vulnerabilities of HW, countermeasures by HW … class number 1References for above items, such as cryptographic algorithms … class number 2

The rest … class number 3

The DB provides the feature to retrieve the papers based on the classification.

6. Quotation frequency
The DB provides the quotation frequency numbers of respective papers until the presenttime. Generally, it is well accepted that the papers quoted much tend to include important
information for security or be fundamental ones for particular areas. However, it should
be noted that the papers such as being stated very before or quoted very much are easy to
be abused by attackers.
Also, the DB provides the function to extract the papers quoted more than fifty or hundredtimes.

7. Implementation environments for information processing functionalities
The information processing functionalities defined in the second chapter will be
implemented by embedded devices in various environments. The implementation
environments are categorized as shown in Table 1.

Table 1

Implementation environments

Implementation
environEnvironment I

Environment II

Environment III

Environment IV

The target

The target

The target

The target

ments

Definition

devicedevicedevicedevice

is

is

is

is

circulaportabportabfixed

ting inle andle andphysicthenotresista

ally

marke

protecnt toand

t and

ted

externprotecavailabfromal

ted by3lecarryinphysicsecurewithoug-awa

alenvirota

yattacknment

limit.

attack

s.

.

s.
Some
financial
Auto mobile

Smartcard

The device

Financial

Mobileequipped

terminal

phone/
Examplesterminals

smart phone
Memory card(e.g. SIM)
USB memory

with counter

Robotmeasures

Medicalsuch asdevicedeleting

Security

internal

deviceinformationfor external
attacks.

The device
fixedin thestrict
securezone
which
isprotec
ted byguards.

The strength of countermeasures for attacks is relied on the implementation
environments above. Typically, the countermeasures required to the information
processing part are mitigated so that the protection by the environment is sufficient. For
example, the attacks “direct accessing for objects” shown in the third chapter are unlikely
in the environment IV above. The level of vulnerability analysis required in security
assurance also tends to be relevant to the matters above.

8. Information assets
Examples of information assets to be protected by the information processing
functionalities defined at the second chapter and the categorization of those assets areshown in Table 2.

Table 2Categorization of assets

Assets I

Assets II
AffectingAffectingAssets IV
Affecting minor

seriouslimitedinfluenc

influenc

influence on life

human

e on life

e on lifeof alife

of aof apersona

persona

persona

l/l/l/

familyConcerning withDefinition

Assets III4familyfamilyAffectinginfluenc
Threatening
nationa
lexistencee oncontinu
ation ofactivitie
s of apublicDamaging large
amountofeconom
ic value

Damaging
limitedamountof
econom
ic value

institution
Damaging

Affectingseriousinfluenc
e oncivic life

Threatening
subsistence ofa
corporation

Affecting acontinuedactivityof acorporation

limitedamountof
economic
activitie
s of acorporation

A part of a
Important

information

infrastructure

Information

system of a

Examples(energy,system of acorporationoffinancial,public agency

A electronic

A point systemsyscommunicatio

Information

money system

A gameten, etc.)

system of a

A smallsystemms

Governmental

corporation

personal

information

Smart house

information

systemmanagementsystem

5

Smartcard for
public services
Traffic devices(automobile,Examples

airplane, etc.)

ofMedicaldev

devices

ice

Some robots

sWeapons
Importantguard devices

Smart meter

Credit/debit

Some robots

card

Supplemental

Financialguard devices

devices such

Informationas ATMappliances

Store

Controlterminals

equipments

FeatureStation service

phonesSmart phones

apparatus

Prepaidelectronicmoney cardsAttending/lea
ving
management
devices
Some store
terminals

Tablet devices
ExamplesofParts such as M2M modules should follow the highest level of the assets

parof the device in which they are embedded.

tsStrength of the countermeasures to counter an attack is relied on the information assets
above. Typically, the strength of the countermeasures that an information processing unit
possesses is required much so that the value of the asset becomes high.
The level of vulnerability analysis in security assurance is relevant to the problem above.

9. The relationship between attack patterns and implementation environment
The relationship between the attack patterns shown in the fourth chapter and theimplementation environments shown in the seventh chapter is shown in Table 3.

Table 3

The relationship between the attack patterns and theimplementation environments

Implementation
environEnvironment
I

ments

Definition

Environment
II

Environment III

Environment
IVThe target

The target

The target

The target

device isdevice isdevice isdevice iscirculaportabportabfixed

ting inle andle andphysic6the marke t

not protec

resista nt toally andand availa

ted from

extern al

protec ted

ble witho ut

carryi ng-

physic alby securea limit.

aw ayattacks.

enviroattacks.

1. Physicalnment.







































12. Physical
Unclonable
Function

13. Machine
Learning







15.Hardware
TrojanAttacks
2. Overcoming
sensors andfilters
3. Perturbation
Attacks
4. Retrieving
keys withDFA
5. Side-channel
Attacks Non-invasive
retrieving ofsecret data
6. Exploitationof Testfeatures
7. Attacks onRNG
8. Ill-formed
Java Cardapplications
9. Software
Attacks
10. Appletisolation

 : strong

: mediumlownone10. Security assurance
7

The guidance does not require nor recommend developers nor users specificcountermeasures to counter the threats provided by the papers included in
the DB. Instead, it is recommended to utilize the scheme for information
security evaluation and certification based on ISO/IEC 15408 (Common Criteria).
The scheme provides means to assure that an IT product has been designed
and implemented to offer appropriate security features, at the time of theevaluation.
Every participating country of CCRA (CCRA is the international arrangement) is operating
respective own schemes. The attacks defined in the second chapter are not commonevaluation and certification items for all CCRA participants. They are being evaluated andcertified by the CC evaluation and certification schemes in Japan and Europe SOGIS (thecertificate authorizing countries are France, Germany, Italy, Netherlands, Norway, Spain,
Sweden and United Kingdom).
The schemes above are continuously updating the criteria of vulnerability assessment,
which is applied to determine whether an IT product is implemented with necessarysecurity features or not at the time of evaluation. Updates are shared among the schemes.
As updating is done continuously, the criteria of vulnerability assessment is changing withtime. If two certificates were issued on different date, even they provided the same
security assurance level, each evaluation might had been done based on the different
criteria of vulnerability assessment.
The guidance recommends the security assurance level for hardware CC evaluation asfollows. Especially, the seventh chapter “Implementation environments for information
processing functionalities” and the eighth chapter “Information assets” should beconsidered.
For the readers of the guidance, the following procedure is recommended: (i) defines theimplementation environment for the target product and the information assets to beprotected, (ii) extracts the recommended security assurance levels from Table II and III
below and (iii) selects the highest security assurance level among them. The readers
should also recognize that the selected level above should be treated as an aim.
Note. Each security assurance level in Table II and III bellow is not indicated with CC
security assurance level (EAL: Evaluation Assurance Level) but with components ofAVA_VAN, which is a family of vulnerability assessment class. It is used because the CC
evaluation part, which relates information of attacks, countermeasures and vulnerabilities
stored in the DB, is exactly vulnerability assessment of the target product.

Table I [Examples of embedded devices * Value of information assets]
Assets I
Definition

Assets II

Concerning with Affecting
humanserious

Assets III
AffectinglimitedAssets IV
Affecting minor
influenc
8Lifeinfluenc

influence on life

e on life

e on lifeof aof aof apersona

persona

persona

l/l/l/

familyfamilyfamilyAffectinginfluenc
Threatening
nationalexistence

e oncontinu
ation ofactivitie
s of apublicDamaging large
amountofeconom
ic value

Damaging
limitedamountofeconom
ic value

institution
Damaging

Affectingseriousinfluenc
e oncivic life

Threatening
subsistence ofa
corporation

Affecting acontinuedactivityof acorporation

limitedamountofeconomic
activityof acorporation

A part of a

Importantinfrastructure

Information

Examples(energy,system of aoffinancial,public agencysyscommunicatio

Informationten, etc.)

system of ams

Governmental

corporation

information

Smart housesysteminformation
system of acorporation
Electronic

Point systemmoney system

Game system

Small personal
information
management
system9

Smartcard for

Examples
of
dev
ice
s

Smart meter

public services

Traffic device

Some robots

Credit/debit(automobile,Supplemental

card

airplane, etc.)

guard device

Financial

Medical device

Information

device such asSome robots

appliance

ATMWeapons

ControlStore terminal

Importantequipment

Feature phone

guard device

Station service

Smart phoneapparatus

Tablet device

Prepaidelectronicmoney card
Attending/lea
ving
management
deviceSome store
terminals

ExamplesofParts such as M2M modules should follow the highest level of the assets

parof the devices in which they are embedded.

tsTable II[Value of information assets * security assurance]

Value of
infor
matio

Asset I

Asset II

Asset III

Asset IVnassets
Security

It is recommended to apply an appropriate evaluation andassura

certification scheme by third parties for information security

nce

area based on CC and the like.

Recommended
levelofvulner

AVA_VAN.5

AVA_VAN.5

AVA_VAN.4

AVA_VAN.3

abilityassessment

Table III
Implementation[Implementation environments * security assurance]
Environment I

Environment II

Environment III Environment IV10

environments
The target

Definition

The target

devicedeviceisiscirculaportabting inle andthenotmarke

protec

t and

ted

is

from

availacarryin

ble

g-awa

withouyta
limit.

attacks.

The target
devicedeviceisisportabfixed

le andphysicresistaally

nt toandexternprotecal

ted byphysicsecurealenviroattacknments.

.

Somefinancial
Auto mobileSmartcard

FinancialMobile
Examplessecurezone
whichisdeleting

Security

USB memory

strictsuch asdevice(e.g. SIM)in theThe device

measures

MedicalMemory card

fixed

terminals

with counterRobot

smart phone

The device

equipped

terminal

phone/The target

protecinternaldevice

ted byinformation

guardsfor external.

attacks.
It is recommended to apply anappropriate

Security
assuranceevaluationand certification schemebythirdparties

forAssurance for environment basedon ISMS and the like

information security area
based on CC and the like.

Recommended
level ofvulnerability

AVA_VAN.5

AVA_VAN.5

AVA_VAN.4—assessm
ent
Note

Either the high level of vulnerability assessment for the information11

asset or the implementation environment should be selected.

[How to use the tables above](1)

Specify the information assets and the implementation environment of the target
product.

(2)

Select the highest recommended level of vulnerability assessment for theinformation assets or the implementation environments, specified in Table II and
Table III respectively.

12