Overview of security evaluation - COSIC€¦ · Overview of security evaluation Lex Schoonen....

Overview of security evaluation

Lex Schoonen

page 2/46brightsight® your partner in security approval

Overview

Introduction

Schemes

Assurance and Security

Example scheme: Common Criteria


Overview

Introduction

Schemes




Introduction - apology

XKCD:


Globally recognized security evaluation laboratory

Presence in Asia (BeSecure in Japan, Brightsight Asia Pacific)

More than 25 years of experience in IT hardware security

Founded by TNO, since 2004 independent company

40 employees

Annual turnover: 5M Euro

Over 100 regular customers

More than 150 evaluations each year

Brightsight in short


Security Evaluations and Audits

Common Criteria

Payment Card Industry (Card & Terminal)

Proprietary Schemes (Government, Telecom, Automotive, Transport)

Security Training

Workshops at Brightsight

On site security training

Consultancy

Individual support for developers

Support of organizations and stakeholders

Security Analysis Tools

Sideways (Side channel analysis tool, SPA, DPA, EMA, DEMA)

Brightlight (Laser manipulation tool)

Brightscan (Voltage manipulation tool)

Our services


Our accreditations

ISO 17025

ISO 15408: Common Criteria: BSI (Germany), NSCIB (Netherlands), SERTIT (Norway)

Stg. Geheim (Secret) work by Dutch Military Intelligence (MIVD)

EMVCo

MasterCard CAST

VISA Risk Implementation Review and VISA Whitebox

Cryptography Research, Inc. DPA Countermeasure Validation Program

JTEMS

Payment Card Industry (PCI)

Payment Terminal Security (PTS)

UK Payments Administration (UK)

APCA (Australia)

Currence PCI+ (The Netherlands)

EPCI (Belgium)

ZKA (Germany)

EP2 (Switzerland)


Overview

Introduction

Schemes




What is an evaluation scheme

Typically, a scheme is the main stakeholder in a given environment

The scheme has an interest in the security of product

Example: MasterCard

Secure smart cards

Secure payment terminals


Parties in a scheme

Scheme can refer to either the party itself („owner‟) or the whole of procedures and parties

Three parties involved:

The scheme owner

The developers / sponsors

The evaluation labs


Scheme responsibilities

Selects eligible products

Accreditation of evaluation labs

(Defines test methodology and acceptance criteria)

Scheme creates list of “approved” products

Developers submit test report made by independent accredited test lab

Scheme approves on the basis of test report

Issues Certificate

Usually developers pay for test report

Reject

Scheme

Approval


Developer responsibilities

Develop a secure product:

Product must be secure

Development process must be secure

Deployment process must be secure

(Provide documentation)

Usually, the developer is also the party paying for the certification


Evaluator responsibilities

Evaluate product:

Understand product

Vulnerability Analysis

Testing

Report to scheme


Overview

Introduction

Schemes




Assurance and Security (1/2)

Security is „just‟ one property of a product

Security is very hard to quantify

Exhaustive analysis and testing is prohibitively expensive

Choices need to be made about

Security assessment approach

Amount of effort

These choices are usually made on the basis of:

Nature of the product

Usage and environment

Cost of evaluation and expected profit for an attacker


Assurance and Security (2/2)

Usually, the scheme defines a minimal amount of assurance required

Limit on testing effort

Limit on attack potential


Overview

Introduction

Schemes




Common Criteria

Evaluation according to ISO 15408

Originates from software (ITSEC, Orange book)

CC library enables formal description of security functionality and on how to get assurance on security

Evaluation of manufacturer formal claim for security (“Security Target”) by independent lab

Application notes give specifics for application of CC in particular domain;

Well known example:

“JIL application of attack potential to smart cards”

Many countries have certification bodies: FR, UK, NL, GE, Norway, SP, Japan, Korea…

ISO 15408

standard

CC methodology

Library of Security

Functional Requirements

Library of Assurance

Requirements

Application Notes


Common Criteria (2)

Common Criteria

CC assurance covers development, design, implementation and deployment

CC has assurance levels 1 to 7

CC has resistance levels “high”, “medium” and “low”

Assurance that development

processes are adequately organised

and protected

TOEAssurance

that

manufacturer

claim is

correct and

evaluatable

Assurance

that user

deploys the

TOE in a

secure

manner

Assurance that the TOE security works

as intended and is resistant to attacks

ST


Common Criteria: Overview

Manufacturer

(Developer)

Evaluation lab

Government

certification body

Certificate

evaluation

request

evaluation

reportsevaluation

reportsevaluation

reports, rating

design and

test datadesign and

test datadesign and

test data

lab

accreditation

feedback


The TSF shall enforce the [assignment: access control SFP(s) and/or information flow control SFP(s)] to prevent the [selection: disclosure, modification, loss of use] of user data when it is transmitted between physically-separated parts of the TOE.

Common Criteria: example SFR


Workflow of a CC evaluation

Investigation of the security target (ASE)

Formal correctness

Proper description of security problem etc.

Investigation of the product design (ADV)

Correct representation of the functionality described in the ST

Investigation of the product‟s user guidance (AGD)

Will the product be secure if it is used according to the guidance?

Investigation of the developer‟s test approach (ATE)

Depth and coverage

Lifecycle and Development and deployment procedures (ALC)

Will the customer receive the product as it was evaluated?

Vulnerability analysis and penetration testing (AVA)

Is the product as resilient to attacks as claimed in the ST?

Rate all relevant attack paths and perform attacks where required


Overview Part 2

The problem with CC

The smart card industry‟s approach

Threats

Attack Ratings

Ancient examples from the trenches


Overview Part 2

The problem with CC


Threats

Attack Ratings



Common Criteria

CC gives assurance on how well product functionality meets its claims

Assurance levels (EALs) range from 1 to 7

Level 1 is low assurance

Level 7 is very high assurance (formally proven)

Please note that assurance is not equal to security

Common level for banking cards: 4+ or higher

“+” should be read as “augmented”, which means that additional security claims are used

Some chip developers already aimed for level 6 successfully

CC evaluations take quite some time and money:

One year for the first evaluation, 6 months for a repeat

Serious efforts required of developer

Costs between 200k-350k€

Marketing instrument?


The problem with Common Criteria

Since it is a general standard it cannot mandate „meaningful‟ security claims

Example: network OS in non-networked environment

The CAPP provides for a level of protection which is appropriate for an assumed non-hostile and well-managed user community requiring protection against threats of inadvertent or casual attempts to breach the system security. The profile is not intended to be applicable to circumstances in which protection is required against determined attempts by hostile and well funded attackers to breach system security.


Overview Part 2

The problem with CC


Threats

Attack Ratings



How To Solve: protection profiles

Pushed by certification bodies

Defined by industry collaboration

Dedicated to single category of products:Smartcards

Encrypted storage devices (USB, HDD)

Firewalls


Common Criteria (1): Smart Card Protection Profile

chip manufacturer

chip manufacturer

chip manufacturer

Eurosmart

chip manufacturer

Protection

Profile for chips

chip manufacturer

Driven by manufacturers (IC developers)

PP establishes common grounds


Common Criteria (2): Threat list and rating method

chip manufacturers

card vendors

schemes

JIWG

working groups

(ISCI ->JHAS)financial

institutions

JIL document:

Threat list

JIL document:

Rating method

evaluation labs

Threats: Attack Methods for Smart Cards and Similar Devices, V1.5, February 2009

Rating: Application of Attack Potential to Smart Cards, V2.7, March 2009


Overview Part 2

The problem with CC


Threats

Attack Ratings



Attack Methods for Smart Cards and Similar Devices, V1.5, February 2009

Limited distribution

Application of Attack Potential to Smart Cards, V2.7, March 2009

Contains some examples

Threats according to JIL (1/2)


Physical attacks

Overcoming sensors and filters

Perturbation attacks

Retrieving keys with DFA

SPA/DPA

Higher order DPA

EMA attacks

Exploitation of test features

Attacks on RNG

Ill-formed Java Card applications

Software attacks

Information gathering

Editing commands

Direct protocol attacks

Man-in-the-middle attacks

Replay attacks

Bypass authentication or access control

Buffer overflow or stack overflow

Threats according to JIL (2/2)


Overview Part 2

The problem with CC


Threats

Attack Ratings



Rating

Need for comparing “security strength” of products

Reduce subjectivity

Common Criteria rating method is a well accepted reference

Refined for smart cards in Joint Interpretation Library (JIL) document:

Application of attack potential on smart cards, JIL v2.4, April 2007

CC Rating results in absolute number score


Factors for rating

JIL/CC rating method

Factors Identification Exploitation

Elapsed time X1 Y1

Expertise X2 Y2

Knowledge of TOE X3 Y3

Access to TOE X4 Y4

Used equipment X5 Y5

Open samples X6 Y6

Attack phases

Rating result = total sum of all X and Y


JIL rating method

Range of values

0 - 15

16 - 20

25 - 30

31 and above High

Resistance to attacker with

attack potential of:

No rating

Basic

Moderate

Rating of resistance

Rank total X + Y in table

21 - 24 Enhanced-Basic


Rating

Elapsed time Identification Exploitation

< one hour 0 0

< day 1 3

< one week 2 4

< one month 3 6

> one month 5 8

Not practical * *

* = Results in rating “High”

Elapsed time (JIL)


Rating

Expertise Identification Exploitation

Layman 0 0

Proficient 2 2

Expert 5 4

Multiple expert 7 6

Expertise (JIL)


Rating

Knowledge of the TOE Identification Exploitation

Public 0 0

Restricted 2 2

Sensitive 4 3

Critical 6 5

Very Critical hardware design 9 na

na = not applicable

Knowledge of TOE (JIL)


Rating

Access to TOE Identification Exploitation

< 10 samples 0 0

< 100 samples 2 4

> 100 samples 3 6

Not practical * *

* = Results in rating “High”

Access to Target of Evaluation (JIL)


Rating

Equipment Identification Exploitation

None 0 0

Standard 1 2

Specialized 3 4

Bespoke 5 6

Multiple bespoke 7 8

Equipment (JIL)


Standard:

UV-light emitter

Flash light

Low-end visible-light microscope

Climate chamber

Voltage supply

Analogue oscilloscope

Chip card reader

PC or work station

Signal analysis software

Signal generation software

Specialized:

High-end visible-light microscope and camera

UV light microscope and camera

Micro-probe Workstation

Laser equipment

Signal and function processor

High-end digital oscilloscope

Signal analyzer

Tools for chemical etching (wet)

Tools for chemical etching (plasma)

Tools for grinding

Bespoke:

Scanning electron microscope (SEM)

E-beam tester

Atomic Force Microscope (AFM)

Focused Ion Beam (FIB)

New Tech Design Verification and Failure Analysis Tools

Rating


Rating

Open samples Identification Exploitation

Public 0 na

Restricted 2 na

Sensitive 4 na

Critical 6 na

Open samples (JIL)


Overview Part 2

The problem with CC


Threats

Attack Ratings



Conclusions

Common Criteria offers an elaborate and well-structured framework for evaluation

It is important to understand that the security of the certified product depends on

Security Target

User Guidance

The product itself

Loopholes are present

For certain industries, protection profiles provide a solution

Date post:	25-May-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

Overview of security evaluation - COSIC€¦ · Overview of security evaluation Lex Schoonen....

Documents