Remote Attestation Procedures for virtualized NSFs (vNSFs) through the I2NSF Security Controller
draft-pastor-i2nsf-vnsf-attestation-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Antonio Pastor , Diego Lopez | ||
| Last updated | 2015-10-19 | ||
| Replaced by | draft-pastor-i2nsf-nsf-remote-attestation | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-pastor-i2nsf-vnsf-attestation-00
Network Working Group A. Pastor
Internet-Draft D. Lopez
Intended status: Experimental Telefonica I+D
Expires: April 20, 2016 October 18, 2015
Remote Attestation Procedures for virtualized NSFs (vNSFs) through the
I2NSF Security Controller
draft-pastor-i2nsf-vnsf-attestation-00
Abstract
This document describes the procedures a user can follow to assess
the trust on a virtualized NSF and its user-defined configuration
through the I2NSF Security Controller. The procedure to assess
trustworthiness is based on a remote attestation between the user and
the vNSF.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 20, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Pastor & Lopez Expires April 20, 2016 [Page 1]
Internet-Draft Remote Attestation for vNFs October 2015
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. User Expectations about Trust . . . . . . . . . . . . . . . . 4
2.1. First Step: User-Agnostic Attestation . . . . . . . . . . 4
2.2. Second Step: User-Specific Attestation . . . . . . . . . . 4
3. Application of Trusted Computing . . . . . . . . . . . . . . . 5
3.1. Applying Trusted Computing . . . . . . . . . . . . . . . . 8
4. Trusted vNSF Platforms . . . . . . . . . . . . . . . . . . . . 9
4.1. Requeriments for a Trusted vNSF Platform . . . . . . . . . 9
4.1.1. Trusted Boot . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Remote Attestation Service . . . . . . . . . . . . . . 10
4.1.3. Secure Boot . . . . . . . . . . . . . . . . . . . . . 10
5. Remote Attestation Procedures . . . . . . . . . . . . . . . . 10
5.1. Trusted Channel with the Security Controller . . . . . . . 11
5.2. Security Controller Attestation . . . . . . . . . . . . . 12
5.3. Platform Attestation . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Pastor & Lopez Expires April 20, 2016 [Page 2]
Internet-Draft Remote Attestation for vNFs October 2015
1. Introduction
As described in [I-D.pastor-i2nsf-merged-use-cases], when
virtualization is applied to the NSF environment (vNSF) it implies
several additional concerns in security. The most relevant threats
associated with a security virtual platform are:
o An unknown/unauthorized user can try to impersonate another user
that can legitimately access virtualized NSF services. This
attack may lead to accessing the policies and applications of the
attacked user or to generate network traffic outside a the
security functions with a falsified identity.
o An authorized user may misuse assigned privileges to alter the
network traffic processing of other users in the virtualization
platform. This can become especially serious when such a user has
administration privileges granted by the virtualization provider,
the ISP or the local network operator.
o A user may try to install malformed elements (policy or
application), trying to directly take the control of a NSF or
virtualization platform (for example by exploiting a vulnerability
on one of the functions or may try to intercept or modify the
traffic of other users in the same platform.
o A malicious virtualization provider can modify the software
running on it (the operating system or a concrete vNSF) to alter
the behaviour of the latter. This event has a high impact on all
users accessing vNSFs as the virtualization provider has the
highest level of privilege on the software in execution.
o A user with physical access to the virtualization platform can
modify the behavior of hardware components, or the components
themselves. Furthermore, it can access a serial console (most
devices offer this interface for maintenance reasons) to access
the NSF software with the same level of privilege of the
virtualization provider.
Mutual authentication and, what is more important, the attestation of
the virtualization platform and the vNSFs by users could address
these threats to an acceptable level of risk.
The user can have a proof that their vNSFs and policies are correctly
(from the user point of view) enforced by the Security Controller.
Taking into account the threat identified above, this document first
identifies the user expectations regarding remote trust
establishment, briefly analyzes Trusted Computing techniques, and
finally describes the proposed mechanisms for remote establishment of
Pastor & Lopez Expires April 20, 2016 [Page 3]
Internet-Draft Remote Attestation for vNFs October 2015
trust through the Security Controller.
2. User Expectations about Trust
From a high-level standpoint, in a virtualized I2NSF platform, the
user connects and authenticates to the Security Controller, which
then initialises the user's vNSFs and policies. Afterwards, the user
traffic reaches the Internet via the virtualized platform which hosts
the user's vNSFs. The user's expectations of the platform behavior
are thus twofold:
o The user traffic will be treated according to the user-specified
vNSFs and policies, and no other processing will be performed by
the Security Controller or the platform itself (e.g. traffic
eavesdropping).
o Each vNSF (and its corresponding policies) behaves as configured
by the user.
We will refer to the attestation of these two expectations as the
"user-agnostic attestation" and the "user-specific attestation".
2.1. First Step: User-Agnostic Attestation
This is the first interaction between a user and a Security
Controller: the user wants to attest that he is connected to a
genuine Security Controller before he continues with the
authentication. In this context, two properties characterise the
genuineness of the Security Controller:
1. That the identity of the Security Controller is correct
2. That it will process the user's credentials and set up the user
vNSFs and policies properly.
Once these two properties are proven to the user, the user knows that
their credentials will only be used by the Security Controller to set
up the execution platform for their vNSFs.
2.2. Second Step: User-Specific Attestation
From the security enforcement point of view, the user agnostic
attestation focuses on the initialization of the execution platform
for the vNSFs. This second step aims to prove to the user that their
security is enforced accordingly with their choices (i.e. vNSFs and
policies). The attestation can be performed at the initialization of
the vNSFs, before the user traffic is processed by the vNSFs, or
Pastor & Lopez Expires April 20, 2016 [Page 4]
Internet-Draft Remote Attestation for vNFs October 2015
during the execution of the vNSFs.
Support of static vNSF attestation is REQUIRED for a Security
Controller managing vNSFs, and MUST be performed before the user
traffic is redirected through any set of vNSFs. The Security
Controller MUST provide a proof to the user that the instantiated
vNSFs and policies are the ones chosen.
Additionally to the vNSFs instantiation attestation, a continuous
attestation of the vNSFs execution MAY be required by a user to
ensure their security.
3. Application of Trusted Computing
In a nutshell, Trusted Computing (TC) aims at answering the following
question: "As a user or administrator, how can I have some assurance
that a computing system is behaving as it should?". The major
enterprise level TC initiative is the Trusted Computing Group [TCG],
which has been established for more than a decade, that primarily
focuses on developing TC for commodity computers (servers, desktops,
laptops, etc.).
The overall scheme proposed by TCG for using Trusted Computing is
based on a step-by-step extension of trust, called a Chain of Trust.
It uses a transititive mechanism: if a user can trust the first
execution step and each step correctly attests the next executable
software for trustworthiness, then a user can trust the system.
Pastor & Lopez Expires April 20, 2016 [Page 5]
Internet-Draft Remote Attestation for vNFs October 2015
+-----------+
| | extends PCR
| Platform +------------------------+
| | |
+-----^-----+ |
| |
|measures |
+-----------+ |
| Security | extends PCR |
| +---------------------+ |
| Controller| | |
+-----^-----+ | |
| | |
|measures +-v--v----------+
+-----------+ | |
| | extends PCR | |
| Bootloader+-------------------> Root of Trust |
| | | |
+-----^-----+ | |
| +-^--^----------+
|measures | |
+-----------+ | |
| | extends PCR | |
| BIOS +---------------------+ |
| | |
+-----^-----+ |
| |
|measures |
+-----------+ |
| Bootblock | extends PCR |
| (CRTM) +------------------------+
| |
+-----------+
Figure 1: Applying Trusted Computing
Effectively, during the loading of each piece of software, the
integrity of each piece of software is measured and stored inside a
log that reflects the different boot stages, as illustrated in the
figure above. Later, at the request of a user, the platform can
present this log (signed with the unique identity of the platform) to
the user, which can be checked by the user to prove the platform
identity and attest the state of the system. The base case for the
extension of the Chain of Trust is called the Core Root of Trust.
This Core Root of Trust (CRTM) encompasses the minimal combination of
hardware and software elements that a remote verifier needs to trust
in order to validate the entire Chain of Trust.
Pastor & Lopez Expires April 20, 2016 [Page 6]
Internet-Draft Remote Attestation for vNFs October 2015
From the Chain of Trust extension point of view, any component that
needs to be attested is considered an adversary and must not be able
to modify its behaviour measurement. It is then necessary the use of
hardware mechanisms in combination with software components to create
a strong unforgeable identity and provide safer storage of secrets.
Therefore the main components of the Core Root of Trust are:
1. A specialized hardware component to store the log and
measurements away from the software access
2. An initial isolated component that is able to measure the first
non-trusted software, which will be then trusted to measure the
next stage software.
The TCG has created a standard for the the design and usage of a
secure cryptoprocessor to address the storage of keys, general
secrets, identities and platform integrity measurements: the Trusted
Platform Module (TPM). Since the TPM is located outside of the
execution path it cannot measure it, thus the need of a second
trusted component to do the measurements and send them to the TPM.
The initial straightforward solution was to trust the first to-be-
executed block of software, using extensive auditing or formal
verification for example; but this is still an implicit trust since
nothing guarantees the user that it is the actual executed code. The
CRTM can be strengthened by either an out-of-band discrete component
or through in-band enforcement.
When using a TPM as a root of trust, measurements of the software
stack are stored in special on-board Platform Configuration Registers
(PCRs) on a discrete TPM. There are normally a small number of PCRs
that can be used for storing measurements, however it is not possible
to directly write to a PCR; instead measurements must be stored using
a process called Extending PCRs.
The extend operation can update a PCR by producing a global hash of
the concatenated values of the previous PCR value with the new
measurement value, for example: PCR = SHA-1 ( PCR | measurement )
The Extend operation allows for an unlimited number of measurements
to be captured in a single PCR, since the size of the value is always
the same and it retains a verifiable ordered chain of all the
previous measurements. Furthermore, it is computationally infeasible
for an attacker to calculate two different hashes that will match the
same resulting value of an PCR extend operation.
Pastor & Lopez Expires April 20, 2016 [Page 7]
Internet-Draft Remote Attestation for vNFs October 2015
3.1. Applying Trusted Computing
Attestation of the virtualization platform will thus rely on a
process of measuring the booted software and storing a chained log of
measurements, typically referred to as Trusted Boot. The user must
be able to sent a nonced query of the state of a platform to the Root
of Trust for a signed set of platform measurements. The user will
either validate the signed set of measurements with a trusted third
party verifier who will assess whether the software configuration is
trusted, or the user can check for themselves against their own set
of reference digest values (measurements) that they have obtained a
priori, and having already known the public endorsement key of the
remote Root of Trust. Optionally, to preserve the privacy of a
platform identity, an Attestation Identity Key (AIK) can be generated
and used by the Root of Trust for the purpose of attestation instead
of the Public Endorsement Key. This must be done in conjunction with
a third party Privacy Certificate Authority (CA) who is trusted to
not reveal the real identities, but to act as an intermediary.
As well as for providing a signed audit log of boot measurements, the
PCR values can also be used as an identity for dynamically decrypting
encrypted blobs on the platform (such as encryption keys or
configurations that belong to operating system components). Software
can choose to submit pieces of data to be encrypted by the Root of
Trust (which has its own private asymmetric key and PCR registers)
and only have it decrypted based on a criteria. This criteria can be
that the platform booted into a particular state (e.g. a set of PCR
values). Once the desired criteria is described and the sensitive
data is encrypted by the root of trust, the data has been sealed to
that platform state. The sealed data will only be decrypted when the
platform measurements held in the the root of trust match the
particular state.
As described above, Trusted Boot requires the use of a root of trust
for safely storing measurements and secrets. Since the Root of Trust
is self-contained and isolated from all the software that is
measured, it is able to produce a signed set of platform measurements
to a local or remote user. Trusted Boot however does not provide
enforcement of a configuration, since the root of trust is a passive
component not in the execution path, and is solely used for safe
independent storage of secrets and platform measurements. It will
respond to attestation requests with the exact measurements that were
made during the software boot process. Sealing and unsealing of
sensitive data is also a strong advantage of Trusted Boot, since it
prevents leakage of secrets in the event of an untrusted software
configuration.
Trusted Boot should not be confused with a different mechanism known
Pastor & Lopez Expires April 20, 2016 [Page 8]
Internet-Draft Remote Attestation for vNFs October 2015
as "Secure Boot", as they both are designed to solve different
problems. Secure Boot is a mechanism for a platform owner to lock a
platform to only execute particular software. Software components
that do not match the configuration digests will not be loaded or
executed. This mechanism is particularly useful in preventing
bootkits from successfully infecting a platform on reboot. A common
standard for implementing Secure Boot is described in [UEFI]. Secure
Boot only enforces a particular configuration of software, it does
not allow a user to attest or quote for a series of measurements.
4. Trusted vNSF Platforms
In the I2NSF environment users directly interact with the Security
Controller, which will become the essential element to implement the
measurements described in the procedures described above, relaying on
a TPM for the Root of Trust.
4.1. Requeriments for a Trusted vNSF Platform
Although a discrete hardware TPM is RECOMMENDED, relaxed alternatives
(such as embedded CPU TPMs, or memory and execution isolation
mechanisms) MAY also be applied when the required level of assurance
is lower. This reduced level of assurance MUST be communicated to
the user by the Security Controller during the initial mutual
authentication phase.
4.1.1. Trusted Boot
All users who interact with a Security Controller MUST be able to:
a. Identify the Security Controller based on the public key of a
Root of Trust.
b. Retrieve a set of measurements of all the base software the
Security Controller has booted (i.e. the vNSF platform).
This requires that firmware and software MUST be measured before
loading, with the resulting value being used to extend the
appropriate PCR register. The following list describes which PCR
registers SHOULD be used during a Trusted Boot process:
o PCRs 00-03: for use by the CRTM (Initial EEPROM or PC BIOS)
o PCRs 04-07: for use by the bootloader stages
o PCRs 08-15: for use by the booted base system
Pastor & Lopez Expires April 20, 2016 [Page 9]
Internet-Draft Remote Attestation for vNFs October 2015
4.1.2. Remote Attestation Service
A service MUST be present for providing signed measurements from the
RoT to the end user.
NOTE: The details for the remote attestation protocol have to be
defined.
4.1.3. Secure Boot
Using a mechanism such as Secure Boot helps provide strong prevention
of software attacks. Furthermore, in combination with a hardware-
based TPM, Secure Boot can provide some resilience to physical
attacks (e.g. preventing a class of offline attacks and unauthorised
system replacement). For vNSF platform providers, it is RECOMMENDED
that Secure Boot is employed wherever possible with an appropriate
firmware update mechanism, due to the possible threat of software/
firmware modifications in either public places or privately with
inside attackers.
5. Remote Attestation Procedures
The establishment of trust with the Security Controller and the vNSF
platform consists of three main phases, which need to be coordinated
by the user through a trusted application executed by a trusted
network-attached device:
1. Trusted channel with the Security Controller. During this phase,
the user securely connects to the Security Controller to avoid
that user data can be tampered with or modified by an attacker if
the network cannot be considered trusted. The establishment of
the trusted channel is completed after the next step.
2. Security Controller attestation. During this phase, the user
verifies that the Security Controller components responsible for
handling the user's credentials and for the isolation with
respect to other potential users are behaving correctly.
Furthermore, it is verified that the identity of the platform
attested is the same of the one presented by the Security
Controller during the establishment of the secure connection.
3. Platform attestation. During this step, that can be repeated
periodically until the user connection is terminated, the
Security Controller verifies the integrity of the elements
composing the user vNSF platform. The components responsible for
this task have been already attested during the previous phase.
Pastor & Lopez Expires April 20, 2016 [Page 10]
Internet-Draft Remote Attestation for vNFs October 2015
+----------+
3. Attestatation | Trusted | 3. Attestatation
+--------------------> Third <----------+
| | Party | |
| +----------+ +----------------+
+----------v-------+ | +-----v-----+ |
| User Application | | | Security | |
| | 1. Trusted channel | | Controller| |
| 2. Get Cert +------+ handshake+----------> | |
| 3. Attestatation | | +-----------+ |
| 4.Cont. handshake| | |
| | | |
| | | +---------+ |
| | | | vNSF | |
| | | +---------+ |
+------------------+ +----------------+
Figure 2: Steps for remote attestation
In the following each step, as depicted in the above figure, is
discussed in more detail.
5.1. Trusted Channel with the Security Controller
A trusted channel is an enhanced version of the secured channel that,
differently from the latter, requires the integrity verification of
the contacted endpoint by the other peer during the initial
handshake. However, simply transmitting the integrity measurements
over the channel does not guarantee that the platform verified is the
channel endpoint. The public key or the certificate for the secure
communication MUST be included as part of the measurements presented
by the contacted endpoint during the remote attestation. This way, a
malicious platform cannot relay the attestation to another platform
as its certificate will not be present in the measurements list of
the genuine platform.
In addition, the problem of a potential loss of control of the
private key must be addressed (a malicious endpoint could prove the
identity of the genuine endpoint). This is done by defining a long-
lived Platform Property Certificate. Since this certificate connects
the platform identity to the AIK public key, an attacker cannot use a
stolen private key without revealing his identity, as it may use the
certificate of the genuine endpoint but cannot create a quote with
the AIK of the other platform.
Finally, since the platform identity can be verified from the
Pastor & Lopez Expires April 20, 2016 [Page 11]
Internet-Draft Remote Attestation for vNFs October 2015
Platform Property Certificate, the information in the certificate to
be presented during the establishment of a secure communication are
redundant. This allows for the use of self-signed certificates, what
would simplify operational procedures in virtualized environments,
especially when they are multi-tenant. Thus, in place of
certificates signed by trusted CAs, the use of self-signed
certificates (which still need to be included in the measurements
list) is RECOMMENDED.
The steps required for the establishment of a trusted channel with
the Security Controller are as follows:
1. The user application begins the trusted channel handshake with
the selected Security Controller.
2. The certificate of the Security Controller is collected and used
for verifying the binding of the attestation result to the
contacted endpoint.
3. The user application performs Security Controller attestation
either locally or with the help of a Trusted Third Party.
4. If the result of the attestation is positive, the application
continues the handshake and establishes the trusted channel.
Otherwise, it closes the connection.
5.2. Security Controller Attestation
During the establishment of the trusted channel, the user attests the
Security Controller by verifying the identity of the contacted
endpoint and its integrity. Initially the Security Controller
measures all the hardware and software components involved in the
boot process, in order to build the chain of trust.
Since a user terminal may not have enough capabilities to perform the
integrity verification of a Security Controller the user application
MAY request the status of a Security Controller to a Trusted Third
Party (TTP), which is in charge of communicating with it. This
choice has the additional advantage of preventing an attacker from
easily determining the software running at the Security Controller.
If the user application directly performs the remote attestation it
performs the following steps:
1. Ask the Security Controller to generate an integrity report with
the format defined in [TSCGIRSS].
Pastor & Lopez Expires April 20, 2016 [Page 12]
Internet-Draft Remote Attestation for vNFs October 2015
2. The Security Controller retrieves the measurements and asks the
TPM to sign the PCRs with an Attestation Identity Key (AIK).
This signature provides the user with the evidence that the
measurements received belong to the Security Controller being
attested.
3. Once the integrity report has been generated it is sent back to
the user application.
4. The user application first checks if the integrity report is
valid by verifying the quote and the certificate associated to
the AIK, and then determines if the Security Controller is
behaving as expected, i.e. its software has not been compromised
and isolation among the users connected to it is enforced. As
part of the verification, the application also checks that the
digest of the certificate, received during the trusted channel
handshake, is present among measurements.
If the user application is running on a terminal with low computation
resources, it may contact a TTP which, in turn, attests the Security
Controller and returns the result of the integrity evaluation to the
user, following the same steps depicted above.
5.3. Platform Attestation
The main outcome of the Security Controller attestation is to detect
whether or not it is correctly configuring the virtualization
container for the vNSFs belonging to the connecting user (the
virtualization platform, or vNSF platform) in a way that the user's
traffic is processed only by the NSFs within the container. The
platform attestation, instead, evaluates the integrity of the NSFs
running within the platform. The steps are essentially similar to
the ones described in the previous section.
Attesting vNSFs typically running as virtual machines can become a
rather costly operation, especially if periodic monitoring is
required by the requested level of assurance, and there are several
proposals to make them feasible, from the proposal of virtual TPMs in
[VTPM] to the application of Virtual Machine Introspection through an
integrity monitor described by [VMIA].
6. Security Considerations
This document is specifically oriented to security and it is
considered along the whole text.
Pastor & Lopez Expires April 20, 2016 [Page 13]
Internet-Draft Remote Attestation for vNFs October 2015
7. IANA Considerations
This document requires no IANA actions.
8. References
8.1. Normative References
[I-D.pastor-i2nsf-merged-use-cases]
Pastor, A., Lopez, D., Wang, K., Zhuang, X., Qi, M.,
Zarny, M., Majee, S., Leymann, N., Dunbar, L., and M.
Georgiades, "Use Cases and Requirements for an Interface
to Network Security Functions",
draft-pastor-i2nsf-merged-use-cases-00 (work in progress),
June 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[TCG] "Trusted Computing Group (TCG)",
<https://www.trustedcomputinggroup.org/>.
[TSCGIRSS]
"Infrastructure Work Group Integrity Report Schema
Specification, Version 1.0",
<https://www.trustedcomputinggroup.org/>.
8.2. Informative References
[UEFI] "UEFI Specification Version 2.2 (Errata D), Tech. Rep.".
[VMIA] "Verifying system integrity by proxy".
[VTPM] "vTPM:Virtualizing the Trusted Platform Module", <https://
www.usenix.org/legacy/events/sec06/tech/berger.html>.
Pastor & Lopez Expires April 20, 2016 [Page 14]
Internet-Draft Remote Attestation for vNFs October 2015
Authors' Addresses
Antonio Pastor
Telefonica I+D
Zurbaran, 12
Madrid, 28010
Spain
Phone: +34 913 128 778
Email: antonio.pastorperales@telefonica.com
Diego R. Lopez
Telefonica I+D
Zurbaran, 12
Madrid, 28010
Spain
Phone: +34 913 129 041
Email: diego.r.lopez@telefonica.com
Pastor & Lopez Expires April 20, 2016 [Page 15]