1、 ETSI GR NFV-SEC 007 V1.1.1 (2017-10) Network Functions Virtualisation (NFV); Trust; Report on Attestation Technologies and Practices for Secure Deployments Disclaimer The present document has been produced and approved by the Network Functions Virtualisation (NFV) ETSI Industry Specification Group
2、(ISG) and represents the views of those members who participated in this ISG. It does not necessarily represent the views of the entire ETSI membership. GROUP REPORT ETSI ETSI GR NFV-SEC 007 V1.1.1 (2017-10)2 Reference DGR/NFV-SEC007 Keywords NFV, trust services ETSI 650 Route des Lucioles F-06921 S
3、ophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice The present document can be downloaded from: http:/www.etsi.org/standards-search The
4、 present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such
5、versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on t
6、he current status of this and other ETSI documents is available at https:/portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https:/portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notificatio
7、n No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI. The content of the PDF version shall not be modified without the written authorization of ETSI. The copyright and th
8、e foregoing restriction extend to reproduction in all media. ETSI 2017. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are trademarks of ETSI registered for the benefit of its Members. 3GPPTM and LTE are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
9、Organizational Partners. oneM2M logo is protected for the benefit of its Members. GSM and the GSM logo are trademarks registered and owned by the GSM Association. ETSI ETSI GR NFV-SEC 007 V1.1.1 (2017-10)3 Contents Intellectual Property Rights 5g3Foreword . 5g3Modal verbs terminology 5g31 Scope 6g32
10、 References 6g32.1 Normative references . 6g32.2 Informative references 6g33 Definitions and abbreviations . 7g33.1 Definitions 7g33.2 Abbreviations . 7g34 Attestation Procedures 7g34.0 Introduction 7g34.1 Basic Concepts . 7g34.1.1 Roots of Trust . 7g34.1.1.1 Overview. 7g34.1.1.2 Hardware Based Root
11、 of Trust 8g34.1.1.3 RoT for virtualised platforms 8g34.1.1.4 Security services of RoTs 8g34.1.2 Chain of Trust . 8g34.1.3 Attestation . 9g34.1.4 Supporting Technologies 10g34.1.4.1 Measured Boot 10g34.1.4.2 Load-Time Measurement 10g34.2 Enforcement of System Integrity 11g34.3 Trustworthy Platform C
12、onfiguration 11g34.4 Remote Attestation of VNFs 12g34.4.1 Introduction. 12g34.4.2 Known Challenges 13g34.4.3 Single-Channel VM-Based Deep Attestation . 14g34.4.4 Multiple-Channel Independent Deep Attestation 15g35 Levels of Assurance . 15g35.0 Introduction 15g35.1 Attestation and Assurance 17g35.1.0
13、 Introduction. 17g35.1.1 Platform Attestation 17g35.1.2 Virtual Machine Attestation 17g36 Infrastructure Capabilities 17g36.0 Introduction 17g36.1 Roots of Trust . 18g36.1.1 Overview 18g36.1.2 Root of Trust for Measurement . 18g36.1.3 Root of Trust for Storage 18g36.1.4 Root of Trust for Reporting 1
14、8g36.1.5 Examples of implementation of Roots of Trust 19g36.1.5.1 Trusted Platform Module 19g36.1.5.2 Hardware Security Module . 20g36.1.5.3 Hardware Co-Processors, Chipset, Processor Modes 20g36.2 Measured Boot . 20g36.3 OS Measurement Architecture . 20g36.4 Secure Boot 21g36.5 OS Enforcement of In
15、tegrity 21g36.6 Remote Attestation . 21g36.7 Other Capabilities . 21g36.8 Levels of Assurance to Capabilities Mapping 22g3ETSI ETSI GR NFV-SEC 007 V1.1.1 (2017-10)4 7 Operational Procedures 22g37.0 Introduction 22g37.1 Platform Deployment . 23g37.1.1 Deployment Specific Processes 23g37.1.2 Mutual Ke
16、y Registration . 23g37.1.2.1 Attestation Key Generation . 23g37.1.2.2 Attestation Key Registration . 23g37.1.2.3 Remote Verifier Secure Channel . 23g37.1.3 Golden measurements registration 24g37.2 Attestation Cycle 24g37.2.1 Attestation flow 24g37.2.2 Attestation intervals 25g38 Analysis of the Evol
17、ution of Attestation Technologies 25g38.1 Network Service (NS) Attestation 25g38.2 Infrastructure Network Attestation Using a SDN Verifier . 26g38.3 Perspectives for Run-Time Attestation . 27g38.4 Attestation using HMEE based technology 28g3Annex A: Possible Proof of Concepts . 29g3Annex B: Authors
18、Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (https:/ipr.etsi.org/). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carr
19、ied out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Trademarks The present document may include trademarks and/or tradenames whic
20、h are asserted and/or registered by their owners. ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does not constitute an en
21、dorsement by ETSI of products, services or organizations associated with those trademarks. Foreword This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Network Functions Virtualisation (NFV). Modal verbs terminology In the present document “should“, “should not“, “may
22、“, “need not“, “will“, “will not“, “can“ and “cannot“ are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions). “must“ and “must not“ are NOT allowed in ETSI deliverables except when used in direct citation. ETSI ETSI GR NFV-SEC 007
23、V1.1.1 (2017-10)6 1 Scope The present document discusses existing attestation technologies and practices, as applicable to NFV systems, addressing: The identification and definition of levels of assurance The assumed capabilities from the NFVI (e.g. TPM, HSM, etc.) Operational procedures A gap analy
24、sis of current (established or newly proposed) attestation technologies Recommendations for follow-on PoCs to demonstrate feasibility of the attestation procedures Given the current status of attestation technologies and standards, the present document is applicable to hypervisor-based NFV deploymen
25、ts only, with the exception of some of the perspectives analysed in clause 8. 2 References 2.1 Normative references Normative references are not applicable in the present document. 2.2 Informative references References are either specific (identified by date of publication and/or edition number or v
26、ersion number) or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies. NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI canno
27、t guarantee their long term validity. The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area. i.1 ETSI GS NFV 003 (V1.2.1) (2014-12): “Network Functions Virtualisation (NFV); Terminology for M
28、ain Concepts in NFV“. i.2 ETSI GS NFV 002 (V1.2.1) (2014-12): “Network Functions Virtualisation (NFV); Architectural Framework“. i.3 ETSI GS NFV-SEC 012 (V3.1.1) (2017-01): “Network Functions Virtualisation (NFV) Release 3; Security; System architecture specification for execution of sensitive NFV c
29、omponents“. i.4 TCG, PC Client WG: “PC Client Specific Implementation Specification for Conventional BIOS“, V1.21 Errata, rev 1.0, 2012-02. i.5 TCG, Infrastructure WG: “TCG Attestation, PTS Protocol: Binding to TNC IF-M“, V1.0, rev 28, 2011-08. i.6 ETSI GR NFV-SEC 009 (V1.2.1) (2017-01): “Network Fu
30、nctions Virtualisation (NFV); NFV Security; Report on use cases and technical approaches for multi-layer host administration“. i.7 ETSI GR NFV-SEC 003 (V1.2.1) (2016-08): “Network Functions Virtualisation (NFV); NFV Security; Security and Trust Guidance“. i.8 Unified Extensible Firmware Interface Fo
31、rum: “Unified Extensible Firmware Interface Specification“, V2.7, 2017-05. i.9 NIST SP800-155,draft, 2011-12: “BIOS Integrity Measurement Guidelines“. i.10 TCG PC Client WG: “TCG EFI Platform Specification“, V1.22, rev 15, 2014-01. ETSI ETSI GR NFV-SEC 007 V1.1.1 (2017-10)7 i.11 TCG Virtual Platform
32、 WG: “Virtualised Trusted Platform Architecture Specification“, V1.0, rev 0.26, 2011-09. i.12 TCG TPM WG: “Trusted Platform Module Library Specification“, V1.38, 2016-09. i.13 Andre Rein, 2017: “DRIVE: Dynamic Runtime Integrity Verification and Evaluation“, Proceedings of the 2017 ACM on Asia Confer
33、ence on Computer and Communications Security. NOTE: Available at http:/dl.acm.org/citation.cfm?id=3052975. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the terms and definitions given in ETSI GS NFV 003 i.1 apply. 3.2 Abbreviations For the purposes of the
34、 present document, the abbreviations given in ETSI GS NFV 003 i.1 and the following apply: CoT Chain of Trust CRTM Core Root of Trust for Measurement HBRT Hardware Based Root of Trust LoA Level of Assurance RoT Root of Trust SML Stored Measurement Log TPM Trusted Platform Module 4 Attestation Proced
35、ures 4.0 Introduction Both authentication (a process of ensuring that the computing platform can prove that it is what it claims to be) and attestation (a process of proving that a computing platform is trustworthy and has not been breached) are necessary steps to ensure secure computing in NFV envi
36、ronment. Attestation procedures create assurances of computing platforms integrity state and ability to protect data in accordance with policy. 4.1 Basic Concepts 4.1.1 Roots of Trust 4.1.1.1 Overview The trust status of a computing platform can be determined by a remote party only by using inherent
37、ly trusted primitives embedded into that platform. These primitives are called Roots of Trust (RoTs). The RoTs are expected to behave always according to their predefined purpose, as no other mechanism is available to fully check their behaviour. The RoTs are ideally implemented in hardware or prote
38、cted by hardware mechanisms and provide very specific services to the computing platform they are serving. For attestation of a computing platform, three main services types are required to be supported by its RoTs: Protection of cryptographic material (e.g. keys) Isolated execution of cryptographic
39、 operations Bootstrapping code measurement ETSI ETSI GR NFV-SEC 007 V1.1.1 (2017-10)8 4.1.1.2 Hardware Based Root of Trust In NFV deployments it is expected that the virtualisation layer (i.e. hypervisor) will make use of a Hardware Based Root of Trust (HBRT). The HBRT should be implemented in a har
40、dware component that fulfils the requirements defined in ETSI GS NFV-SEC 012 i.3. The HBRT provides a subset of the services required for enabling a remote party to compute the trust status of the virtualisation host. 4.1.1.3 RoT for virtualised platforms Unlike the virtualisation layer, which is ex
41、pected to run directly on the hardware of the compute node, the VNFCIs will run on virtualised platforms. They may run in an execution environment created by the hypervisor based on dedicated hardware support. The same principle applies to the RoTs available to the virtualised platform: the virtual
42、platform can make use of dedicated hardware features provided by the HBRT (as defined in ETSI GS NFV-SEC 012 i.3), but the hypervisor is involved in configuring this access and sometimes transferring messages between VNFCIs and their associated hardware rooted vRoTs. Therefore, a vRoTs represents th
43、e combination of hardware functionality provided by the HBRT and the relevant components of the hypervisor that configure and mediate access to those functionalities. In NFV deployments, it is highly desirable to restrict as much as possible the influence of the hypervisor on the vRoTs. Coupled with
44、 the host hardening requirements of ETSI GS NFV-SEC 012 i.3, this would ensure the best available protection for the vRoTs. If HMEE technology is used to host and protect virtual RoTs, one possibility to integrate them in the CoT is to tether them to their corresponding HBRT implementation (e.g. TPM
45、, HSM). 4.1.1.4 Security services of RoTs A RoT provides one or more security services to the platform, e.g. software measurement service for the Root of Trust for Measurement (RTM), software measurement and measurement validation service for the Root of Trust for Verification (RTV), access controll
46、ed and tamper evident or tamper resistant protected storage service for the Root of Trust for Storage (RTS), certification service (providing cryptographic proof that a set of data originates from the RTS) for the Root of Trust for Reporting (RTR). The term RTM is used in the present document to rep
47、resent the origin of the Chain of Trust (CoTs) (see clause 4.1.2), as the present document is primarily focused on exploring Remote Attestation technologies. Wherever Secure Boot/Local Attestation is instead referenced within the present document, it should be assumed that the origin of the CoT is,
48、in that case, the RTV. 4.1.2 Chain of Trust A CoT, also known as a Transitive CoT, is used to infer trust in the measurement data of the software component that represents the last link of the chain. Trust is initially only bestowed on the first link in the chain, the Root of Trust for Measurement (
49、RTM). Starting from the RTM the principle of “first measure and record, then execute“ is applied by all software components that are executed on the given platform. It ensures that all software components are measured at load time and cannot tamper with their own measurement procedure. The RTM performs the first measurement, which will be implicitly trusted, because of the defining property of the RTM - immutability (as defined by TCG PC Client Specific Implementation Specification for Conventional BIOS i.4). Thus trust c
