Understanding Maat Features 
********************************

.. Copyright

   Copyright 2023 United States Government

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.

.. currentmodule:: maat

.. |sngCol| raw:: html

  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

.. |break| raw:: html

  <br>

Purpose and Intended Audience
-----------------------------
This document describes the requirements of Measurement and Attestation (M&A) systems and discusses the features that an M&A system would have to possess in order to meet these requirements.

The intended audience for this section is anyone that wants to have a better understanding of why Maat's integrity evaluations should be trusted when Maat measures a target platform and what the motivation for the design of Maat's architecture and the selection of its feature set.

General requirements
--------------------
The Maat team has identified the following general requirements for any M&A system in general and Maat in particular:

.. table:: Requirements for M&A system design
   :widths: 3 8
   :column-wrapping: true true

   ====================== ============================================================================================
   Requirement            Description
   ====================== ============================================================================================
   Completeness           Maat must be capable of producing measurement data that is sufficient for the trust decision
                          to determine if the target is the extected target, as required for all of the measurement
                          scenarios supported by the integrity management system.
   Freshness              Maat must be capable of producing measurement data that reflects the target's state recently
                          enough for the trust decision to be satisfied that the measured state is sufficiently close
                          to the current state as required for all the measurement scenarios supported by the
                          integrity measurement system.
   Semantic Explicitness  Maat must address the degree to which the measurement data contains the necessary evidence
                          required for the trust decision that triggered the attestation.
   Authenticity           Maat must guarentee that the evidence was generated by a reliable source and reflects the
                          target of interest.
   Correctness            Maat must be a sound design and correct implementation of all the M&A component mechanisms.
   Protection             Maat must be protected from the target of measurement to prevent the target from corrupting
                          the measurement process or data in any way the trust decision cannot detect.
   Flexibility            Maat must be capable of producing measurement data with enough variability to satisfy
                          potentially differing requirements of the trust decision for the different measurement
                          scenarios supported by the integrity management system.
   Useability             Maat must be capable of producing measurement data in a format that enables easy evaluation
                          of the expectedness of the target as required for all of the measurement scenarios supported
                          by the integrity management system.
   ====================== ============================================================================================

Completeness, freshness, and semantic explicitness provide quality evidence to the Appraiser for trust decisions.

Authenticity, correctness, and protection inform the Appraiser that measurements can be trusted.

Flexibility and use-ability provide for the support of multiple appraisers, measurement agents, attestation protocols,
and select appropriate mechanisms in the context of the given trust decision.

Capabilities
------------
Maat incorporates the capabilities defined in this section to meet the requirements of an M&A system.
As shown in the table below, all criteria are met.

.. figure:: images/capabilities_vs_requirements.jpg
   :align:  center

   Summary table showing which capabilities of Maat fulfill the requirements of an M&A system

The capabilities are defined in the following subsections.

Multiple Appraisers
===================
Platform integrity evaluations may be required in a wide variety of circumstances and may be evaluated by one  or more different appraisers. Each appraiser may have its own notions of what evidence is required to show integrity, and how that evidence should be collected and presented. A flexible M&A system should be usable across a range of appraisers to prevent duplication and fragmentation of M&A functionality.

Multiple Attestation Protocols
==============================
Attestation protocols determine how evidence is collated and presented for evaluation. For example, one protocol may produce a aggregate measurement report with a single signature covering all measurement, another protocol may produce a signed report per piece of evidence collected, and a third may produce a chain of reports where each signature covers a report and the hash of the previous signed report. These three protocols can all present the same primary evidence, but the appraiser may be able to draw different conclusions on the freshness and authenticity of the data based on the different bundling style. Allowing the policy-driven selection of protocols to suit the needs of each specific attestation scenario enhances the flexibility and usability of the M&A system.

Multiple Measurement Agents
===========================
Measurement agents provide concrete evidence gathering capabilities. Different evidence may be required to show the integrity of different components or to provide varying levels of confidence in one component. Some measurement agents may provide only boot time evidence of integrity, such as a TPM quote, while others may generate fresher evidence showing integrity at runtime. Additionally, appraisers may require the use of a specific measurement agent implementation to ensure correctness, e.g., an appraiser may accept the reports of a malware scanner from one vendor but not another. It is important for the M&A service to allow for policy-driven selection of measurement agents appropriate to a scenario. Like support for multiple appraisers and protocols, this feature directly supports the flexibility and usability of the M&A system.

Policy Based Negotiations
==========================
The M&A service should be capable of negotiating with a peer to select a protocol and evidence set that satisfies each peer’s policy. As a general rule, appraisers are likely to seek the most detailed evidence of attester integrity possible. Attesters are likely to want to limit disclosure of sensitive platform information, such as detailed memory information. Both parties may want to limit the resources required to complete the attestation. Support for policy-based negotiation allows the parties to find a protocol and evidence pair that is consistent with these goals. The need for policy based negotiation is largely a consequence of support for multiple appraisers, protocols, and agents and thus contributes to the flexibility and usability of the system.
In order to safely perform this negotiation, the peers should have a pre-existing security association such as could be established by the isakmp protocol.
Having this association allows each party to reliably identify its peer and make appropriate selections.

Discrete M&A Functions
======================
To ensure the trustworthiness of their measurements, the service should ensure that measurement agents are protected from both the target of their measurement and from other parts of the measurement framework. For example, measurement agents may require exceptional authority, such as the ability to read kernel memory or attach a debugger to arbitrary processes. These privileges should be isolated in the smallest possible components and carefully controlled via platform access control policy. Isolating M&A functionality into discrete components also allows for fine grained policy regarding the authenticity and correctness properties of each component.

Support for Registration
========================
To support extensibility of the supported attestation protocols and measurement agents, the service should support a registration mechanism that ensures only valid combinations are available for negotiation, and that the platform’s security policy is enforced for all installed components. Registration ensures that only correct components are accessible by the M&A system, that the purpose of these components is explicitly defined, and that these components will be correctly protected, and that their reports are authentic because they cannot be circumvented.

Portability
===========
The M&A service should support deployment in a wide range of systems and be able to govern different M&A components within a single system. The M&A service may be installed on client systems, servers, or embedded devices. In a virtualized system, an instance of the M&A service may run in the host, hyper-visor, guest, and/or dedicated virtual machines (VM). In order to provide a complete platform view, the M&A service should be designed and implemented in such a way that it can function in any of these contexts.

Composability
=============
Integrity evaluations may require the gathering and evaluation of evidence from multiple administrative realms within a single platform, or potentially from across multiple hosts. Multiple instances of the M&A service should be able to work together to delegate both evidence collection and evaluation tasks to the most appropriate instance. These instances may be installed on separate physical hosts, separate virtual machines on the same physical platform, or within the same operating system instance configured to have authority over different parts of the system. Because measurement functionality must be protected from the target of measurement, providing a complete evaluation of a virtualized platform may involve cooperation between instances of the M&A service in a guest VM, in an administrative VM, and in the virtual machine monitor itself.

Complex, State-based Measurements
=================================
The service should allow for complex evidence collection. An attestation may require invoking a collection of measurement agents that each inspect a different aspect of the target state. To perform a complete evaluation, collected evidence or intermediate evaluation results may introduce additional measurement requirements. For example, if a software inventory measurement shows that a kerberos authentication package is installed, a measurement of the kerberos configuration may be required. Similarly, if a measurement of a process shows that it has a writable memory location shared with another process, a measurement of the second process may be required. These kinds of recursive measurement dependencies necessitate M&A support for incremental discovery of measurement requirements.

References
-----------

|  Attestation: Evidence and Trust
|     http://web.cs.wpi.edu/~guttman/pubs/icics_attestation.pdf
|  Principles of Remote Attestation
|     https://link.springer.com/article/10.1007/s10207-011-0124-7
|  A Platform Service for Remote Integrity Measurement and Attestation
|     https://ieeexplore.ieee.org/document/8599735
|  Orchestrating Layered Attestations
|     https://link.springer.com/chapter/10.1007%2F978-3-030-17138-4_9
|  Technical Report: A Toolkit for Runtime Detection of Userspace Implants
|     https://arxiv.org/abs/1904.12896
