TPM 2.0 Security Evaluation
Trust and Confidence
TCG Security Evaluation Work Group September
2017©2017 Trusted Computing Group

Presentation outline• SEWG publications• Common criteria scheme overview– TPM 2.0 Protection profile• Common criteria Evaluation scope• FIPS 140-2 overview– FIPS guidance for TPM 2.0 evaluation• Leveraging certified TPM products• Questions and answers©2017 Trusted Computing GroupTCG Security Evaluation WG
Public documents
Published documents• TCG Protection Profile PC Client Specific TPM Family 2.0
Level 0 Version 1.0 (for TPM 2.0 Revision 1.16)
https://trustedcomputinggroup.org/wpcontent/uploads/TCG_PP_PC_client_specific_TPM_SecV2_v10.pdf• TCG FIPS 140-2 Guidance for TPM 2.0 Version 1.0 Revision 1.0
https://trustedcomputinggroup.org/wpcontent/uploads/TCG_FIPS_140_Guidance_for_TPM2_0_v1r1_20170202.pdf

TCG draft document in Public Review (Sept 12 -> Nov 10)• TCG Protection Profile PC Client Specific TPM 2.0 Version 1.1(for TPM 2.0 Revision 1.38)
https://trustedcomputinggroup.org/wpcontent/uploads/TCG_PP_PC_client_specific_TPM_SecV2_v1.1_r12a_END_NOV10_PR.pdf©2017 Trusted Computing GroupTCG Certification Programfor PC Client TPM• PC client TPM certification is built on 2 quality
criteriaInteroperability• Functional compliance Vs specifications• Evidence: TCG compliance test suite pass results

Security• Evaluation compliant with TCG TPM Protection profile• Evidence: Common criteria certificate• List of certified PC Client TPMs is available on
TCG Website©2017 Trusted Computing GroupA (too) short introduction toCOMMON CRITERIA©2017 Trusted Computing GroupWhat is Common Criteria?
• International Standard (IS0 15408) for the independent
evaluation of the security of IT products• Current version = CC3.1 R5 (April 2017)• Standardised Security Requirements tailorable to fit securityservices• Predefined scale of Evaluation Assurance Levels (EAL1 to 7)• Two-level evaluation: accredited lab and scheme• Mutual Recognition between national schemes (CCRA)• Has its own terminology and acronyms
Evidence

Product
developer

Evaluation Reports

Evaluator
Evaluator

Product Developer(Us)

SchemeScheme(Lab)(Country)(NationalAgency)(Accredited lab)
Evaluation Feedback

Evaluation Feedback

CERTIFICATE©2017 Trusted Computing GroupCC evaluation concepts
Evaluation

Confidence©2017 Trusted Computing Group7

Target Of Evaluation• Target of Evaluation (TOE) – has technicallimits– Defines the evaluation boundary of the product.
– Everything outside the TOE is in the environment©2017 Trusted Computing Group8

Scope of Evaluation• Evaluation Limit– Defines the point at which the TOE is no longer under the control of thedeveloper/manufacturer – based on the lifecycle of the product.

©2017 Trusted Computing Group9

Protection Profile & Security Target• Target Of Evaluation (TOE) - the product or system that is the subject ofthe evaluation.
– “set of software, firmware and/or hardware possibly accompanied byguidance”• Protection Profile (PP) - a document, typically created by a user or user
community, which identifies security functional and assurance
requirements relevant for a particular product. A PP effectively defines aclass of security devices (Printers, Firewalls, TPMs..)– « implementation-independent statement of security needs for a TOE type »• Security Target (ST): the document that identifies the security propertiesof the target of evaluation. Each target is evaluated against the security
functional and assurance requirements defined in the ST.
– Security target may claim compliance to a specific PP (or a set of PPs)

• TCG protection profile defines minimal set of security requirements
to get TCG certification©2017 Trusted Computing Group10PP contents: security problem definition,objectives and requirements©2017 Trusted Computing Group

8 Organisational Security Policies
1. Context Management
2. Policy autorisation
3. Locality
4. Root of Trust for Measurement
5. Root of Trust for Reporting
6. Root of Trust for Storage
7. Field Upgrade
8. Elliptic Curve Direct Anonymous Attestation©2017 Trusted Computing GroupTPM 2.0 PP Threats & Objectives(extracts)
Most objectives are linked to TPM 2.0 functional services.
The ones below focus on non functional security objectives:

Threats

Description

Objective

T.Hack_Crypto

Incorrect cryptographic
implementation leading to key
compromise

O.Crypto_Key_Man

T.Hack_PhysicalUnauthorized disclosure of TOE
assets by hostile user by physicallyinteracting with the TPM

O.Tamper_Resistance

T.LeakInformation exploited to disclose
confidential assets

O.Tamper_Resistance

T.Insecure_StateThe TPM may start or enter insecurestate allowing an attacker to obtain
sensitive data

O.Fail_Secure

T.Residual_Info

Data scavenging

O.No_Residual_Info©2017 Trusted Computing GroupFunctionality and Assurance• Security Assurance provides confidence that Security
Functionality meets its Security Objectives• Therefore CC defines two types of security requirements:– Security Functional Requirements (SFR): the “what?”– Security Assurance Requirements (SAR) the “how?”• Evaluation Assurance Levels (EAL) define coherent set ofSecurity Assurance requirements– EAL gives a global assurance level for an evaluation©2017 Trusted Computing Group

14

Security Functional Requirements• SFRs: a translation of the security objectives of the TOE into astandardized language.
• CC 3.1 Part 2 defines 11 classes containing 65 families of SFRs
• SFRs are assigned a standard identifier:• SFRs are also organized with dependencies to have a commonand coherent approach for all evaluations©2017 Trusted Computing Group15

SFR example from CC Part 2 tailoredfor TPM2.0 PP
Underlined text has been added to match TPM 2.0 specifications©2017 Trusted Computing Group16

SFR Example from TPM 2.0 PP©2017 Trusted Computing Group17

Security Assurance Requirements (1/3)• Security Assurance Requirements (SARs) are descriptions of
how the TOE is to be evaluated• Detailed descriptions for the evaluator of the measures taken
during development and evaluation of the product to assure
confidence with the claimed security functionality.
• For example, an assurance level may require that all sourcecode is kept in a change management system, or that fullfunctional testing is performed.
• The Common Criteria provides a catalogue of these SARs
• The requirements for particular targets or types of products
are documented in the ST and PP, respectively©2017 Trusted Computing Group18

Assurance Classes (2/3)• ADV – Development– Including design and production process of TOE• AGD – Guidance Documents• ALC – Lifecycle Support– Including Configuration management, development
security, tools & techniques, product lifecycle, flaw
remediation• ATE – Tests• AVA – Vulnerability Assessment• ASE – Security Target Assessment• For PP only: APE – Protection Profile Assessment©2017 Trusted Computing Group19

Evaluation Assurance Levels (3/3)©2017 Trusted Computing Group20

Evaluation complexity
Objectives
Threats
SFRs

1234567EAL

Assurance level selection must match market expectations but also system complexity.

©2017 Trusted Computing Group21

TPM 2.0 PP Assurance level1

Augmentations-> EAL4+©2017 Trusted Computing Group22

Vulnerability Analysis• SFR FPT_PHP.3: (fullfilling O.Tamper_Resistance)• SAR AVA_VAN.4: Moderate Attack Potential• AVA_VAN.4: resistance to moderate attack potentials
How to refine evaluation methodology?
• What kind of attacks the product must resist to?
• What’s the link between attacks and assurance levels?
• Attack evolutions security watch?
©2017 Trusted Computing Group23

CC supporting documents for evaluations• CCDB-2013-05-002 :Application of Attack Potential to Smartcards (version 2.9)
• Mandatory document for CC evaluation– used for certified products• Attack rating depending on several factors– Elapsed time
– Expertise– Knowledge of the TOE– Access to the TOE: number of samples (production or test)– Equiment• Vulnerability level « AVA_VAN.x » mandates that TOE must beresistant to attacks up to a specific range.

©2017 Trusted Computing Group24

Vulnerability Analysis Methodology• 1st step: the identification of potential vulnerabilities;– In-depth code/vhdl review• Compliance to design documents and claimed countermeasures• No malicious code, no forgotten bypass functions• 2nd assessment to select attacks scenarios .
• 3rd penetration testing to determine whether the identified potential
vulnerabilities are exploitable in the operational environment– Fault injections: Glitches, Laser, …
– Side Channel Attacks - Leak
• SPA: Static Power Analysis• DPA: Differential Power Analysis• And others– Reverse engineering – Physical hacking• TOE modification©2017 Trusted Computing Group25

Security Attack Watch: SOGIS• Security is a continuous race
– New attack paths appear (Academic papers, Lab, University)– New attacks appear (Labs, Hackers)• SOGIS: group of European countries, CCRA members subset– Including Japan and Turkey as Liaison member• Security watch is covered by one SOGIS working group: JHAS
– JHAS audience not limited to SOGIS – specific registration process• Joint Hardware Attack Subgroup holds meetings– Attendence: Vendors, Labs, National schemes, other certification scheme(EMVCo)– Meeting every 2 months– Follow-up of the new attacks or rating of existing attacks.
– Public document available in « Application of Attack Potential to Smartcards »– Evaluation methodology details are shared between JHAS members©2017 Trusted Computing Group26

CC Recognition Agreement©2017 Trusted Computing Group27

CCRA recognition and Industry
requirements• Up to recently automatic recognition was up to EAL4
• No evaluation methodology agreement above• Nowadays, certificate Recognition between CCRA
countries is automatic but limited up to EAL2(+ALC_FLR)– EAL4+ (ALC_FLR) if Collaborative Protection Profile• TPM PP targets EAL4+ (ALC_FLR & AVA_VAN.4)– > CCRA recognition covered up to EAL2 (+ALC_FLR)©2017 Trusted Computing GroupCollaborative PP and International
Technical communities• Issue: several PPs exist for the same kind of device.
• Proposal: 1 technical committee endorsed by CC unique per device• Collaborative Protection Profile (cPP):
A Protection Profile collaboratively developed by an International Technical Communityendorsed by the Management Committee.
A cPP and related Supporting Documents define the minimum set of common security
functional requirements and the Achievable Common Level of Security Assurance.
It addresses vulnerability analysis requirements to ensure certified products reach anAchievable Common Level of Security Assurance.

• International Technical Community (iTC):
A group of technical experts including Participants, Certification/Validation Bodies, ITSEFs,
developers and users• Several cPPs are under edition – See Common Criteria website©2017 Trusted Computing GroupEvaluation results publication

CC Portal website
https://www.commoncriteriaportal.org/©2017 Trusted Computing GroupAutomotive thin TPM 2.0 Protection Profile• Strict conformance to a PP mandates that TOE implements allSFRs and all SARs from the PP• Automotive thin platform profile is a subset of the PC ClientProfile -> all SFRs may not be implemented-> PC Client PP not usable for evaluation of Automotive thinimplementations• Automotive thin protection profile modifcations at a glance:– Removal of SFRs linked to optional features in automotive thin
– Field upgrade is kept as optional package– SARs are kept unchanged©2017 Trusted Computing GroupFIPS 140-2©2017 Trusted Computing GroupFIPS 140-2 CMVP (short) overview• FIPS 140-2 defines a set of generic security requirements and security
services formalization requirements for products evaluation– Cryptographic Module Specification– Cryptographic Module Ports and Interfaces– Role, Service and Authentication– Finite State Model– Operational Environment– Cryptographic Key Management– EMI/EMC (if applicable)– Self-Tests– Design Assurance– Mitigation of other attacks (optional)• FIPS 140-2 defines 4 compliance levels with different quality criteria• Product features described in a « Security Policy » public document– Available on FIPS CMVP Certified Product List
©2017 Trusted Computing GroupLevel based Criteria
SecurityRequirements

TPM 1.2

TPM 2.0

TPM 2.0©2017 Trusted Computing Group34

FIPS 140-2 CAVP
• Cryptographic Algorithm Validation Program– Correct implementation of approved cryptographicalgorithms– Cryptographic interoperability between FIPS certifiedproducts• Process– CAVP generates test vectors– Vendors receives test vectors and generates test answers– CAVP validates test answers and assign certificates for eachalgorithm– Vendor includes certificate numbers in the Security Policy©2017 Trusted Computing Group35

TCG SEWG deliverables• SEWG released a guidance to help TPM vendors andEvaluation labs for the evaluation of TPM 2.0 implementations• Target level: 2• Main goals were– to factorize standard behaviour description in a form suitable forsecurity policy• E.g. Key management, Selftests, …

– to anticipate conflicts between TPM specifications and FIPS
requirements• TPM 1.2 lessons learnt– to provide additional information regarding TPM optional featuresbecoming mandatory for FIPS requirements fullfillment©2017 Trusted Computing Group36

LEVERAGING CERTIFIED TPM FORSYSTEM EVALUATION©2017 Trusted Computing GroupCC System certification• CC certified TPM simplifies System CC evaluation• Protection profile reusable SFRs
– Cryptographic Services (Including random generator)– Storage, Measurement, Reporting• TPM assets protection configuration• TPM services are already covered by TPM evaluation• System architecture has to describe the settings of the security attributesof TPM assets to comply with platform security functions• System assets protection (TCG use cases)• Define Platform assets• Describe how platform assets are protected by TPM security functions
System Security Target©2017 Trusted Computing GroupFIPS System Certification• FIPS certified TPM simplifies system FIPS evaluation• Cryptographic features reusable– Cryptographic algorithm certificates• Including FIPS approved random generator– Storage, Measurement, Reporting• TPM assets protection configuration• TPM services are already covered by TPM evaluation• System architecture has to describe the settings of the security attributesof TPM assets to comply with platform security functions• System assets protection (TCG use cases)• Define Platform assets• Describe how platform assets are protected by TPM security functions
System Security Policy©2017 Trusted Computing Group39

THANK YOU
Any questions?

©2017 Trusted Computing Group