2015/3/31
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.3

Perturbation Attacks

4.2
4.4

4.5

4.6

4.7

4.8

4.9

4.10

Overcoming sensors and filters
Retrieving keys with DFA

Side-channel Attacks — Non-invasive retrieving of secret data
Exploitation of Test features

Attacks on RNG

Ill-formed Java Card applications

Software Attacks
Applet isolation

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-knowncountermeasures”. They were described originally by this association.

2

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 environments

Environment I

Environment II

Environment III

Environment IV

The target

The target

The target

The target

isis

is

is

deviceDefinition

circulating inthemarket andavailabdeviceportable andnot

protectedfrom

deviceportable andresista
nt toexternaldevice
fixedphysic
allyandprotec
ted by3lecarryin

physicsecuretayattacknment

withoug-awa

limit.

alattacks.

s.

 Somefinancial Auto mobile

 Smartcard

 Financial

 Mobilesmart phone Memory card(e.g. SIM) The device
equipped

terminal

phone/

Examplesterminals

 USB memory

with counter Robotmeasures Medical

such asdevicedeleting

 Security

internal

deviceinformationfor external

attacks.

enviro.

The device

fixedin thestrictsecurezone

whichisprotected 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.

Definition

Table 2Categorization of assets

Assets I

Assets II

Concerning withhumanlife

Affectingseriousinfluence on lifeof apersonal/

Assets III

Affectinglimitedinfluence on lifeof apersonal/Assets IV

Affecting minor

influence on lifeof apersonal/family4

family

Affectingfamilyinfluenc

Threatening

national

existencee oncontinu

ation ofactivitie
s of apublicDamaging large

amountofeconom
ic value

instituti

Damaging

limitedamountofeconom
ic value

onDamaging
Affectingseriousinfluenc
e oncivic life

Threatening

subsistence ofa

corporation

Affecting acontinu
edactivity
of acorporation

limitedamountof

economic

activitie
s of acorporation

 Important
Examplesofsys
tems

infrastructure(energy,financial, A part of a
 Information
system of asystem of a

 A small Governmental

corporation

systemcorporation

 A electronic Information

information

system of apublic agency

communication, etc.)information

 Smart housemoney system
personal A point system
 A gamesystem

information

management

system5 Smartcard for Traffic devicesofdevices

airplane, etc.)

 Medicaldevices

 Some robots

par Supplemental

 Financial

 Informationas ATM Weapons

carddevices suchmoney cards

 Attending/leaving

 Storeequipments

 Featureapparatus

Smart phones

management

terminals

 Station service

 Prepaid

electronic

appliances Control

guard devicesof Credit/debit

guard devices

 Important

Examples Smart meter Some robots(automobile,Examples

public services

devices Some store

phonesterminals

Tablet devices

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

tsof the device in which they are embedded.

Strength 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

Environment

The target

The target

The target

The target

isis

is

is

I

ments

Definition

devicecirculating inII

deviceportable andEnvironment III

deviceportable andEnvironmentIVdevicefixed

physic6

thenot

resistaallyt andted

externprotecmarke
available

witho
ut alimit.
1. Physicalprotecfromcarrying-aw
ay

attacks.

nt toalphysical

attacks.

andted bysecureenvironment.

sensors and3. Perturbation













of Test

7. Attacks onJava Card

9. Software

10. Applet







Attacks

2. Overcoming
filters

Attacks

4. Retrieving
keys withDFA

5. Side-channel
Attacks -Non-invasive
retrieving ofsecret data

6. Exploitation
features
RNG

8. Ill-formed
applications
Attacks

isolation

: strong: medium : low

: none10. 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 andcertification based on ISO/IEC 15408 (Common Criteria). The scheme provides means toassure that an IT product has been designed and implemented to offer appropriate
security features, at the time of the evaluation.

Every participating country of CCRA (CCRA is the international arrangement) is operating

respective own schemes. The attacks defined in the second chapter are not common

evaluation 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 necessary
security 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

Concerning withhuman

Assets II

Affectingserious

Assets III

AffectinglimitedAssets IV

Affecting minor

influenc

8

life

influenc

influence on lifeof aof apersonae on life
personal/familyAffectinge on life
personal/familyinfluenc

Threatening

national

existencee oncontinu

ation ofactivitie
s of apublic

Damaging large

amountofeconomic value

institutiof al/

familyDamaging

limitedamountof

econom
ic valueon

Damaging
Affectingseriousinfluenc
e oncivic life Important
Examples

ofsys
te

ms

infrastructure(energy,financial,Threatening

subsistence ofa

corporation

 Information
system of apublic agency

 Information

 Governmental

corporation

information
systemcontinuedactivityof acorporation
 A part of acommunication, etc.)Affecting asystem of a

 Smart house

limitedamountof

economic

activityof acorporation

information
system of acorporation

 Electronicmoney system Small personal Point system Game system

information

management

system9 Traffic device(automobile,Examplesofdevices

airplane, etc.)

ofpar

 Supplemental
guard device

 Credit/debitcard

 Financial

device such as Information

 Weapons

 Control Store terminal

 Station service

Smart phone Some robots
 Important

appliance

equipment
apparatusATM Feature phone
Tablet device

 Prepaid

electronicmoney card

 Attending/lea
ving

management
device Some store
terminals

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

tsTable II
Value of Some robots

public services

 Medical device

guard device

Examples Smart meter Smartcard for

informatio
nof the devices in which they are embedded.

[Value of information assets * security assurance]

Asset I

Asset II

Asset III

Asset IV

assetsSecurity

assurance

It is recommended to apply an appropriate evaluation andcertification scheme by third parties for information security
area based on CC and the like.

Recommended
levelofvulner
ability

AVA_VAN.5

AVA_VAN.5

AVA_VAN.4

AVA_VAN.3

assessment

Table IIIImplementation[Implementation environments * security assurance]
Environment I

Environment II

Environment III

Environment IV

10environments

The target

The targetisisdevicedevicecirculaThe target

isis

deviceportabting infinancial

 Auto mobile Financial

 Mobile
Examplessmart phone Memory card(e.g. SIM) USB memory.

The device

fixed

terminals

in the The device

strictequipped

terminal

phone/

nments.

s.

 Some Smartcard

enviroattackattacklimit.

securealyta

ted byphysic

g-awa

withouprotecalcarryinbleandexternfrom

availaallynt totedisphysicresistaprotec

t and

fixed

le andnot

marke

deviceportable andtheDefinition

The target

securewith counter Robotzonemeasures Medical

whichsuch asdeviceisdeleting Security

protecinternal

deviceted 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 ofvulnera
bilityAVA_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