Subject: [Rats] Propose a new event-log-type in CHARRA

From: "Panwei (William)" <[email-masked]>
Date: Fri, 28 Aug 2020 13:53:08 +0000

Hi authors, all,

We've proposed a new attested-event-log-type in the Github (PR#5<https://github.com/ietf-rats-wg/basic-yang-module/pull/5>) a while ago, but unfortunately there is little discussion about it. This is also mentioned at IETF 108 meeting. I think it might be better to bring this topic to the mailing list and give more description about it.
The blue part below is the format of the new type of log that we propose. It literally looks somewhat similar to the IMA log format, because it uses part of the IMA's concepts in the devices boot measurement.
When the device boots, it needs to load/execute a lot of files, but the order in which these files are loaded/executed is not deterministic or hard to keep fixed, so it's difficult to give an accurate reference value.
The method to overcome this difficulty is below:
1. The Attester measures each file before execution, extends the hash value of the file into PCR, and records the measurement information of the file in the log.
2. When doing the remote attestation, the Attester sends the final values of the PCRs and the detailed logs to the Verifier.
3. The Verifier has a list of reference values for all files. It compares the hash value of each file recorded in the log with the corresponding reference value. If all files' hash values match with their reference values, then the Verifier extends the hash values one by one according to the order recorded in the log, gets the final value, and compares the final value with the PCR value sent by the Attester.
Based on this method, we propose the new type of log. Any thoughts?

+--ro output
   +--ro system-event-logs
      +--ro node-data* []
         +--ro tpm-name?     string
         +--ro up-time?      uint32
         +--ro log-result
            +--ro (attested-event-log-type)
               +--:(bios)
               |  +--ro bios-event-logs
               |     +--ro bios-event-entry* [event-number]
               |        +--ro event-number    uint32
               |        +--ro event-type?     uint32
               |        +--ro pcr-index?      pcr
               |        +--ro digest-list* []
               |        |  +--ro hash-algo?   identityref
               |        |  +--ro digest*      binary
               |        +--ro event-size?     uint32
               |        +--ro event-data*     uint8
               +--:(netequip-boot)
               |  +--ro boot-event-logs
               |     +--ro boot-event-entry* [event-number]
               |        +--ro event-number               uint64
               |        +--ro filename-hint?             string
               |        +--ro filedata-hash?             binary
               |        +--ro filedata-hash-algorithm?   string
               |        +--ro file-version?              string
               |        +--ro file-type?                 string
               |        +--ro pcr-index?                 pcr
               +--:(ima)
                  +--ro ima-event-logs
                     +--ro ima-event-entry* [event-number]
                        +--ro event-number               uint64
                        +--ro ima-template?              string
                        +--ro filename-hint?             string
                        +--ro filedata-hash?             binary
                        +--ro filedata-hash-algorithm?   string
                        +--ro template-hash-algorithm?   string
                        +--ro template-hash?             binary
                        +--ro pcr-index?                 pcr
                        +--ro signature?                 binary

Regards & Thanks!
Wei Pan

---

From: Ira McDonald <[email-masked]>
Date: Fri, 28 Aug 2020 10:07:43 -0400

Hi,

+1

I've worried about this fragility in RIMs (Reference Integrity Metrics) all
along.

You might be able to fix the boot order of drivers (well maybe not), but you
certainly almost always can't fix the load order of applications and
libraries.

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)Co-Chair - TCG Trusted
Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*

*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://sites.google.com/site/blueroofmusic
<http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc
<http://sites.google.com/site/highnorthinc>mailto: [email-masked]
<[email-masked]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Fri, Aug 28, 2020 at 9:53 AM Panwei (William) <[email-masked]>
wrote:

> Hi authors, all,
>
>
>
> We’ve proposed a new attested-event-log-type in the Github (PR#5
> <https://github.com/ietf-rats-wg/basic-yang-module/pull/5>) a while ago,
> but unfortunately there is little discussion about it. This is also
> mentioned at IETF 108 meeting. I think it might be better to bring this
> topic to the mailing list and give more description about it.
>
> The blue part below is the format of the new type of log that we propose.
> It literally looks somewhat similar to the IMA log format, because it uses
> part of the IMA’s concepts in the devices boot measurement.
>
> When the device boots, it needs to load/execute a lot of files, but the
> order in which these files are loaded/executed is not deterministic or hard
> to keep fixed, so it’s difficult to give an accurate reference value.
>
> 1. The Attester measures each file before execution, extends the hash
> value of the file into PCR, and records the measurement information of the
> file in the log.
>
> 2. When doing the remote attestation, the Attester sends the final values
> of the PCRs and the detailed logs to the Verifier.
>
> 3. The Verifier has a list of reference values for all files. It compares
> the hash value of each file recorded in the log with the corresponding
> reference value. If all files’ hash values match with their reference
> values, then the Verifier extends the hash values one by one according to
> the order recorded in the log, gets the final value, and compares the final
> value with the PCR value sent by the Attester.
>
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Aug 2020 16:37:00 -0400

Panwei (William) <[email-masked]> wrote:
    > order in which these files are loaded/executed is not deterministic or
    > hard to keep fixed, so it's difficult to give an accurate reference
    > value.

    > value of the file into PCR, and records the measurement information of
    > the file in the log.

Does the Attester measure the files in a deterministic order?

    > 2. When doing the remote attestation, the Attester sends the final
    > values of the PCRs and the detailed logs to the Verifier.

I remember this discussion.

    > 3. The Verifier has a list of reference values for all files. It
    > compares the hash value of each file recorded in the log with the
    > corresponding reference value. If all files' hash values match with
    > their reference values, then the Verifier extends the hash values one
    > by one according to the order recorded in the log, gets the final
    > value, and compares the final value with the PCR value sent by the
    > Attester.

Why not impose some canonical ordering (even alphabetical) to how the files
are recorded into the PCR, regardless of the order they are executed?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Panwei (William)" <[email-masked]>
Date: Sat, 29 Aug 2020 02:04:07 +0000

From: Michael Richardson [mailto:[email-masked]]
> Does the Attester measure the files in a deterministic order?

No, the order can't be guaranteed.

> Why not impose some canonical ordering (even alphabetical) to how the
> files are recorded into the PCR, regardless of the order they are executed?

This is not a secure manner, you need to cache the hash values before they are extended into the PCR, so if a malicious file is executed it has the opportunity to change its hash value before being extended into the PCR.
So the secure manner is to extend the hash value of the file into PCR before executing it.

Regards & Thanks!
Wei Pan

> --
> Michael Richardson <[email-masked]>, Sandelman Software
> Works  -= IPv6 IoT consulting =-