Skip to content

AM Config and Library Components

Jump to bottom
komp edited this page Jul 23, 2024 · 2 revisions

AM Configuration and Library Components

The Current Design

(The snippets in this section reflect the state of the ASP Lib Rework branch as of 07/22/2024.)

Currently AM Libraries include the following components:

  Record AM_Library := {
    (* Local Mappings *)
    Lib_ASPs            : MapC ASP_ID Concrete_ASP_ID ;
    Lib_Plcs            : MapC Plc UUID ;
    Lib_PubKeys         : MapC Plc PublicKey ;
    (* Attest <-> Appraisal ASP Mapping *)
    ASP_Compat_Map      : MapC ASP_ID ASP_ID ;
  }.

Currently Manifests include the following components:

  Record Manifest := {
    my_abstract_plc   : Plc ; 

    asps              : manifest_set ASP_ID; 
    uuidPlcs          : manifest_set Plc ;
    pubKeyPlcs        : manifest_set Plc ;
    targetPlcs        : manifest_set Plc ;
    policy            : PolicyT  ;
    (* TO DO: Add privacy and selection policies to manifest? *)
  }.

Proposed Changes

We propose pulling out some of the components that are in the AM Library to help make the AM Library more portable. This will allow for agreement between all parties within an attestation session about certain specific naming issues (such as what the UUID for the place we all call P1 is, or what P1's public key is).

We note that the AM Library is already being treated like a shared structure and is given to multiple AMs so they may establish a shared vocabulary for all the abstract identifiers in the Copland Terms they are executing. The only thing we currently expect to change between two different machines is the file system locations of their ASP binaries. Resolving this would be the duty of a local configuration file separate from the AM Library.

To achieve this end, we propose the modified AM Library:

  Record AM_Library := {
    (* Session-Wide Mappings *)
    Lib_Plcs            : MapC Plc UUID ;
    Lib_PubKeys         : MapC Plc PublicKey ;
    (* Attest <-> Appraisal ASP Mapping *)
    ASP_Compat_Map      : MapC ASP_ID ASP_ID ;
  }.

The Manifest will remain in its same form.

We will ultimately end up needing a local ASP mapping that can take the Session-Wide agreed upon ASP_ID to a local path for executing that ASP. For this we propose the following Jsonifiable structure that will be passed into the Attestation Manager during launch:

  Record Local_ASP_Config := {
    (* Maps ASP_IDs to a location on the Filesystem *)
    ASP_Location_Map      : MapC ASP_ID FS_Location ;
  }

If further down the road we find that more information needs to be locally configurable (such as Plcs, PubKeys, etc.), this structure could be extended to a Local_AM_Config that includes all necessary mappings.

Alternatively (perhaps preferably), we could instead require that all ASP Binaries be located in one ASP_BIN directory that is provided to the AM at launch time. This ASP_BIN will also require that ASP binaries be named the same as their ASP_ID, and invocation will just take place by searching the bin for the ASP_ID. While this approach is less flexible, it may be the most obvious approach to take, and even lend towards ensuring that AM administrators do not miswire something in the Local_ASP_Config that will cause the execution of ASPs to fail, or occur incorrectly. In the event an administrator really needs more configurability for specific ASPs, an ASP_Location_Map could be optionally used to give non-standard paths to a handful of ASPs; however, we believe this practice should be heavily discouraged and would much prefer administrators use the canonical ASP_BIN structure.

Different ASP Implementations on Differrent Machines (Namespacing Idea)

During our discussion tackling the AM Libary, we recognized there may be some instances where two machines use distinct implementations for the same concept, e.g. for hashing algorithms, P1 may use SHA512 while P2 may only be able to use SHA256. This results in different algorithms for appraising evidence from P1 vs. P2. One proposed solution was to have namespacing, such that @P1<filehash> and @P2<filehash> would have explicitly different corresponding appraisal ASPs, indicated by the P1 or P2 namespace. We expect most attestation environments would not suffer from these kinds of differences in limitations, so this would lead to extensive duplication of appraisal ASPs.

We also argue for the following best practices for ASP implementations: either

  1. ASPs should be specific to a certain setup such that good evidence is effectively unchanging (e.g. if the integrity of a specific file on a specific machine must be verified, the known-good hash of that file should be unchanging and the same hashing algorithm should be used every time)

or

  1. ASPs should be dynamic enough to accomodate for minor differences between machines (e.g. if the integrity of a specific file must be verified on multiple machines using different hashing algorithms, the ASP ARGS or evidence returned should indicate which hashing algorithm was used so the appraisal ASP can account for this)

Additionally, if it really is necessary to have separate appraisal ASPs, then we suggest simply using different ASP_IDs (e.g. for the P1 vs. P2 hashing example, it would be possible to simply have two different ASP_IDs, p1_hash and p2_hash). Thus, we do not currently see value in implementing namespacing. This idea can be revisited in the future if we find our current hypothesized attestation environments do not match practical environments.

or another option:

  1. HSH under specifies the function to be applied to the data; and 'p1_hash' vs 'p2_hash' does not resolve the ambiguity, it likely only worsens it. The ASP_IDs I recommend are HASH_SHA512 and HASH_SHA256, as these are two different functions, not different implementations of the same function. Both P1 and P2 probably will have ASPs for both functions. The appraiser will choose which to use in the Copland protocol, based on the golden hash value was computed.

'Sort' is an example for which different ASP's might use different implementations -- one might usa bubble sort, while another uses tree sort -- the results (should be) the same for either implementation, and so a single ASP_ID 'Sort' works fine).

In general, a new ASP_ID should begin with a formal definition of its measurement AND how the result is formatted. If someone proposes an ASP to generate the OS Version of the place, then one needs define the fields of desired output (e.g. OS name, major version, minor version, ...). Different operating systems will require different implementations, but all return a value in the same format; so there is a single ASP_ID.

Clone this wiki locally