Re: [Rats] draft-ietf-rats-architecture-12

[Michael Richardson <[e-mail]>]

Daniel Migault <[e-mail]> wrote:
    > Thanks for the response. Let me rephrase myself.  Suppose that Target
    > Environment and Attesting Environment are different pieces of
    > hardware.

yes, that's somewhat reasonable for some TPM environments.

    > I
    > am saying this mostly as it is unclear to me if TPM is assumed to be part
    > of the CPU or as another piece of hardware.
    > What I was trying to say is that the verifier trusts the Attesting
    > Environment  and will trust in the Evidence.

    > However, there is also an implicit trust the claims retrieved by the
    > Attesting Environment from the Target Environment are not tampered.

yes, we can't defend against that.
If you have such a situation, then you need another Attesting Environment.
The Composite scenario is an example of that.
A real life scenario is a router chassis and a series of line cards.
Another real life scenario is a PC enclosure and smart-NICs and/or GPUs.

    > If we
    > do not have that trust, the Attesting Environment will only be able to
    > attest claims that cannot be trusted.
    > Things can be simplified when the Target Environment and Attesting
    > Environment are part of the same hardware as there is a need to trust the
    > hardware. If the TPM is a different chip, it needs to be extended with the
    > BIOS and we need to trust this is the BIOS actually stored in the ROM.

There are real life attacks against the I2C that is used to talk to the TPM.
They can be mitigated if the I2C communication is encrypted to the TPMs
public key, but this requires that the system "bios" have a secure place to
put the TPM's public key.   This is possible some platforms that have some
secure space inside the CPU.

    > I do not think the figure needs to be changed and become more complex. I
    > think it looks great.

Good.
How can we change the text to include your concern?

    >> My question was what means self-assert in the following sentence:

    > """

    mcr> In layered attestation, a root of trust is the initial Attesting
    mcr> Environment.  Claims can be collected from or about each layer.  The
    mcr> corresponding Claims can be structured in a nested fashion that
    mcr> reflects the nesting of the Attester's layers.  Normally, Claims are
    mcr> not self-asserted, rather a previous layer acts as the Attesting
    mcr> Environment for the next layer.  Claims about a root of trust
    mcr> typically are asserted by an Endorser.

    > """

    > To me, as I understand the figure Claims are provided by the Target
    > Environment to the Attesting Environment. In my view the Attesting
    > Environment is responsible to add some trust to the Claim. Re-reading the
    > text, I have the impression this is what is being said.
    > I think what upset me was the use of self-asserted while the document never
    > put assertion in the Target Environment.

some change needed?

    >> > """
    >> > The
    >> > final Evidence thus contains two sets of Claims: one set about the
    >> > bootloader as measured and signed by the BIOS, plus a set of Claims
    >> > about the kernel as measured and signed by the bootloader.
    >> > """
    >>
    >> > I understand that the set of claims are combined together with for
    >> example
    >> > a hash function. In other words, Evidence is not (necessarily) a
    >> list of
    >> > claims that can easily be extracted from the Evidence.
    >>
    >> Extending a single PCR in a TPM results in a single Claim.
    >> The Claims are not fed into the TPM.
    >> Any hash (ECDSA w/SHA256 for instance) involved in signing the Evidence,
    >> is a
    >> property of the signing algorithm, and not part of the Claim.
    >>
    >> > If my understanding is correct, I would maybe clarify "contains". I
    >> also
    >> > have the impression cascading carries the notion of recurrence where

    >> > section 8.4
    >>
    >> > _Strength of Function_ this is a markdown notation I suspect.
    >>
    >> Yes, and in text form, that's how we represent italics, just like in email.
    >> In HTML it shows up in italics.
    >>

    > sure I was wondering if that were intentional.

Yes, intentional.

    >>
    >> > By default, the Relying Party does not believe the Attester to be
    >> > compliant.  Upon receipt of an authentic Attestation Result
    >>
    >> > I do not see any reason to perform attestation if the Attester is
    >> known to
    >> > be compliant. I am wondering if "by default" is appropriated or
    >> should be
    >> > instead replaced by something around Upon starting an attestation,
    >> the
    >> > Relying....
    >>
    >> In the beginning ("by default"), the universe was without form, and all
    >> Attesters were
    >> untrusted.  Then, on the first day, God created the Verifier, and used it
    >> to
    >> evaluate Evidence, and separated the void into the Trusted and the
    >> Untrusted.
    >>

    > ;-)

. o O ( then the elder ghods caused a post-quantum event... )

    >>
    >> > It is a bit unclear to me what authentic means
    >>
    >> It means, for instance that the signature has checked out.
    >> But, not every system uses signatures directly.
    >> It could also indirect through session security, e.g.: TLS
    >>

    > Does authentic means authenticated then ? If not what is the difference ?

Yes.
Evidence that has had a signature check would be authenticated.
Evidnece that was passed over a secure channel would not be have a signature
check, but would be trusted (due the channel) to be authentic.

    >> Evidence = signed(claims)
    >>
    >>
    > ok. I think the text is fine and that I was influenced by the hash of
    > hashes I wanted to represent a set. Not sure it is not only me.

I think that some of the underlying historic implementation infects the discussion.


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide