Re: [Rats] [EAT] {RATS] Introduction

[Carl Wallace <[e-mail]>]

From:  "Diego R. Lopez" <[e-mail]>
Date:  Thursday, September 13, 2018 at 3:10 AM
To:  "Eric Voit (evoit)" <evoit=[e-mail]>, Carl Wallace
<[e-mail]>, Shawn Willden
<swillden=[e-mail]>, "Smith, Ned" <[e-mail]>
Cc:  "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject:  Re: [EAT] {RATS]  Introduction

> Hi,
>  
> If I am correctly following your proposal, this is connected with the idea of
> a trusted channel we experimented with in the SECURED project, and described
> in draft-pastor-i2nsf-vnsf-attestation:
>  
> “A trusted channel is an enhanced version of the secured channel. It adds the
> requirement of integrity verification of the contacted endpoint by the other
> peer during the initial handshake to the functionality of the secured channel.
> 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.”

This only works if the public key/certificate associated with the remote
endpoint can be obtained initially such that it is known to be correct. It's
common to see artifacts that aim to demonstrate that something is a genuine
product from Example Co without being able to demonstrate that something is
a particular genuine product from Example Co. The latter is often necessary.
Bootstrapping trust is hard, especially where it intersects with privacy
concerns. 
>