ETSI GS NFV-SEC 012-2017 Network Functions Virtualisation (NFV) Release 3 Security System architecture specification for execution of sensitive NFV components (V3 1 1)《网络功能虚拟化(NFV).pdf

《ETSI GS NFV-SEC 012-2017 Network Functions Virtualisation (NFV) Release 3 Security System architecture specification for execution of sensitive NFV components (V3 1 1)《网络功能虚拟化(NFV).pdf》由会员分享，可在线阅读，更多相关《ETSI GS NFV-SEC 012-2017 Network Functions Virtualisation (NFV) Release 3 Security System architecture specification for execution of sensitive NFV components (V3 1 1)《网络功能虚拟化(NFV).pdf（17页珍藏版）》请在麦多课文档分享上搜索。

1、 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 components Disclaimer The present document has been produced and approved by the Network Functions Virtualisation (NFV) ETSI Industry Spe

2、cification Group (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 SPECIFICATION ETSI ETSI GS NFV-SEC 012 V3.1.1 (2017-01)2 Reference DGS/NFV-SEC012 Keywords architecture, NFV, security ETSI

3、650 Route des Lucioles F-06921 Sophia 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:/w

4、ww.etsi.org/standards-search The 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 diff

5、erence in contents between such 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 ch

6、ange of status. Information on the 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/CommiteeSupport

7、Staff.aspx Copyright Notification 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 authorizati

8、on of ETSI. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2017. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTE are T

9、rade Marks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI GS NFV-SEC 012 V3.1.1 (2017-01)3 Contents Intellectual Property Rights 4g3Foreword . 4g3Modal verbs termin

10、ology 4g31 Scope 5g32 References 5g32.1 Normative references . 5g32.2 Informative references 5g33 Definitions and abbreviations . 6g33.1 Definitions 6g33.2 Abbreviations . 6g34 Principles 7g34.1 Introduction 7g35 Platform requirements 7g35.1 Core hardware requirements. 7g35.2 Core software requireme

11、nts 8g36 Lifecycle . 9g36.1 Trusted Computing Base 9g36.2 Workload provisioning . 9g36.3 Runtime checks 10g36.4 Entropy and random numbers 10g36.5 Cryptographic primitives 11g36.6 Installed software and configurations on host system 12g36.7 De-provisioning workloads 12g36.8 Dealing with failure 13g3

12、6.8.0 General points . 13g36.8.1 Requirements relating to failure conditions 13g37 External dependencies 13g38 Architecture section 13g38.0 System hardening techniques . 13g38.1 Secure logging 14g38.2 OS-level access and confinement control . 14g38.3 Physical controls and alarms 14g38.4 Authenticati

13、on controls 14g38.5 Access controls . 14g38.6 Communications security . 15g38.7 Boot 15g38.8 Attestation 15g38.9 Hardware-mediated execution enclaves . 15g38.10 Hardware-Based Root of Trust (HBRT) 15g38.11 Self-encrypting storage . 15g38.12 Direct access to memory 16g38.13 Hardware Security Modules

14、. 16g38.14 Software integrity protection and verification 16g3History 17g3ETSI ETSI GS NFV-SEC 012 V3.1.1 (2017-01)4 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any

15、, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); 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

16、 the ETSI Web server (https:/ipr.etsi.org/). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried 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 ma

17、y be, or may become, essential to the present document. Foreword This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Network Functions Virtualisation (NFV). Modal verbs terminology In the present document “shall“, “shall not“, “should“, “should not“, “may“, “ne

18、ed 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 GS NFV-SEC 012 V3.1.1

19、 (2017-01)5 1 Scope The present document defines requirements for host system elements on which sensitive workloads are to be run. The present document defines requirements to ensure isolation of sensitive workloads from non-sensitive workloads sharing a platform. The present document discusses a wi

20、de range of different technologies which aim to increase the security of a host system for the workloads which will be executing on it. 2 References 2.1 Normative references References are either specific (identified by date of publication and/or edition number or version number) or non-specific. Fo

21、r specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies. Referenced documents which are not found to be publicly available in the expected location might be found at https:/docbox.etsi.org/Re

22、ference. NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. The following referenced documents are necessary for the application of the present document. 1 ETSI TS 133 310: “Universal Mobile Telecommunications Sys

23、tem (UMTS); LTE; Network Domain Security (NDS); Authentication Framework (AF) (3GPP TS 33.310)“. 2 ETSI TS 133 210: “Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE; 3G security; Network Domain Security (NDS); IP network layer secur

24、ity (3GPP TS 33.210)“. 3 ISO/IEC 18031:2001: “Information technology - Security techniques - Random bit generation or equivalent specification“. 2.2 Informative references References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For

25、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 cannot guarantee their long term validity

26、. 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 NIST Publication (SP) 800-90B: “Recommendation for the Entropy Sources Used for Random Bit Generation“. i.2 NIST Publication (SP)

27、800-88 revision 1: “Guidelines for Media Sanitization“. i.3 ETSI GS NFV-SEC 009: “Network Functions Virtualisation (NFV); NFV Security; Report on use cases and technical approaches for multi-layer host administration“. i.4 Greg Hoglund, Gary McGraw (2007): “Exploiting Online Games: Cheating Massivel

28、y Distributed Systems“, Addison-Wesley, New Jersey. i.5 ETSI TS 103 487 “CYBER; Baseline security requirements regarding sensitive functions for NFV and related platforms“. i.6 ETSI TR 103 309: “CYBER; Secure by Default - platform security technology“. ETSI ETSI GS NFV-SEC 012 V3.1.1 (2017-01)6 i.7

29、NIST SP800-123: “Guide to General Server Security“. i.8 NIST SP800-125: “Guide to Security for Full Virtualization Technologies“. i.9 ISO/IEC 15408: “Information technology - Security techniques - Evaluation criteria for IT security - Part 1: Introduction and general model“. i.10 ETSI GR NFV-SEC 003

30、: “Network Functions Virtualisation (NFV); NFV Security; Security and Trust Guidance“. i.11 ETSI GS NFV-INF 004 (V1.1.1): “Network Functions Virtualisation (NFV); Infrastructure; Hypervisor Domain“. i.12 TCG: “Virtualized Trusted Platform Architecture Specification“, Version 1.0, Revision 0.26. i.13

31、 NIST SP 800-162: “Guide to Attribute Based Access Control (ABAC) Definition and Considerations“. 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: host system: collection of hardware, software and firmware making up

32、the system which executes workloads NOTE 1: When the host system is part of the NFVI, it is the “hypervisor“ and “host“ as defined by ETSI NFV-INF 004 (V1.1.1) i.11. In the case of virtualisation of workloads within the MANO domain, there is no corresponding definition available. NOTE 2: The definit

33、ion in ETSI NFV-INF 004 i.11 specifically excludes containers, but the present document does not. workload: component of the NFV architecture that is virtualised in the context of a particular deployment 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: A

34、BAC Attribute-Based Access Control DH Diffie-HellmanDHE Diffie-Hellman Exchange DSA Digital Signature Algorithm ECDH Elliptic Curve Diffie-Hellman ECDHE Elliptic Curve Diffie-Hellman Exchange ECDSA Elliptic Curve Digital Signature Algorithm ECP Elliptic Curve modulo a Prime GMAC Galois Message Authe

35、ntication Mode HBRT Hardware-Based Root of Trust HMEE Hardware-Mediated Execution Enclave ICV Integrity Check Value HSM Hardware Security Module IOMMU Input-Output Memory Management Unit MANO MANagement and Orchestration MODP More mODular exPonential NIST National Institute of Standards and Technolo

36、gy PKI Public Key Infrastructure PRF Pseudo-Random Function RNG Random Number Generator RSA Rivest-Shamir-AdlemanETSI ETSI GS NFV-SEC 012 V3.1.1 (2017-01)7 SSL Secure Sockets Layer TCB Trusted Computing Base TCG Trusted Platform Group TLS Transport Layer Security TPM Trusted Platform Module 4 Princi

37、ples 4.1 Introduction Trust, as defined in ETSI GR NFV-SEC 003 i.10, is an important component of security. One weakness of software as opposed to hardware, is that software can be copied in whole or in part. Trust that is rooted in software may be less reliable than trust rooted in hardware, quickl

38、y, easily, and any number of times. For the particular case of sensitive workloads that have to be trusted, only the highest assurance in the root of trust is considered acceptable, thus for the purposes of the present document the root of trust shall be provided in hardware. There is, however, a co

39、ncomitant concern that when a device is subject to black box testing, it is impossible to determine if the responses to interrogation come from hardware or software. To counter this, a NFVI vendor shall be able to provide evidence on demand that the root of trust is a hardware element. The means by

40、which the vendor provides such evidence is not considered in the present document but should be mutually agreed between the vendor and operator. A vendor shall be able to provide evidence on demand to authorized parties of the security claims for the root of trust. The means by which the vendor prov

41、ides such evidence is not considered in the present document, but should be mutually agreed between the vendor and operator. An examples of 3rda party assurance programme is Common Criteria (defined in ISO/IEC 15408 i.9). The host system, acting as a black box (closed) environment, shall provide acc

42、ess to authorized external entities only to those capabilities identified in the authorization agreement. 5 Platform requirements 5.1 Core hardware requirements 1) The host system shall implement a Hardware-Based Root of Trust (HBRT) as Initial Root of Trust with the following requirements: - The HB

43、RT shall be both physically and electronically tamper-resistant. - The HBRT shall be both physically and electronically tamper-evident. - The HBRT physical and software interfaces between the HBRT and other hardware components of the host system to which it directly communicates shall be protected f

44、rom eavesdropping, manipulation, replay or similar attacks. - The level of resistance against attacks of the HBRT shall be verifiable and trustable using a certification process. - It shall be possible to restrict the booting procedure if assistance from the HBRT is not available or the HBRT current

45、ly does not contain valid cryptographic material. - Any tampering to the HBRT should lead to detectable degradation of its function. - The HBRT shall be physically protected such that any attempts to remove or replace the HBRT shall cause physical damage to both the HBRT and host system hardware to

46、which the HBRT is attached, rendering both inoperable. ETSI ETSI GS NFV-SEC 012 V3.1.1 (2017-01)8 - The HBRT shall be (physically and/or logically) bound to the host system, so that any attempt to remove the HBRT will be detected and prevent normal operation of the host system. - The HBRT shall incl

47、ude an Immutable Unique Identification value physically linked to the physical root of trust that can be used as identification of the platform. This value shall be stored in a shielded location protected from unauthorized use and disclosure. - The HBRT shall provide capabilities to allow itself to

48、be part of an attestation function. - The host system shall have a mechanism to discover the tampered/non-tampered status of the HBRT. - The host system shall have an interface to provide authorized external services with information about the tampered/non-tampered status of the HBRT. - The host sys

49、tem shall provide a mechanism to report to authorized external services when tamper events occur. - The HBRT shall implement a key management function with the requirements in the following bullet 2. 2) The host system shall implement a key management system which includes key generation, key storage, key deletion and cryptographic processing with the following requirements: - The cryptographic material shall be stored in a shielded location, protected against eavesdropping and physical and environmental tampering. - The key genera