How to verify boot-image integrity?

The current draft hardcodes the use of both the MD5 and SHA1 hash algorithms for the purpose of enabling a device to verify a downloaded boot-image, that may not have an embedded signature.

                  +--ro boot-image
                     +--ro modules
                     |  +--ro module*
                     |     +--ro name?       yang:yang-identifier
                     |     +--ro revision?   string
                     +--ro name       string
                     +--ro md5        string
                     +--ro sha1       string
                     +--ro uri*       inet:uri

But a recommendation came (attribution?) to try to use a digest format more generic and less obsolete. Here are some options:

do nothing, keep as md5 and shall
replace both with sha256 // still hardcoded, but current
define an identity base type ("digest-algorithm") and some derived types for popular dgst lags

Any other ideas?

From Aug 15th (no objections were raised).

This issue was discussed in Berlin. The minutes capture the following:

Issue #17:
RW: My preference is NOT to do nothing. I support option #3 - encode both.
KW: it is good not to have to worry about outdated security methods, hence option 1 is not a good idea.

Listening to the audio recording, it seems that we were leaning towards option #3 - that is, a format that allows us to use SHA256 now, and gracefully add support for additional algorithms in the future if needed.

During the meeting, we discussed an option for the Security Area to quickly publish a new draft defining a generic hashing format, but I’m not sure if it’s needed, as it seems that we could more easily do it using a ‘choice’ statement as follows:

 container boot-image {
    leaf name {
       type string;
    }
    choice name {
       leaf sha256 {      <--- this would be the only choice for now
          type string;
       }
       mandatory true;
    }
    <snip/>
 }

In this way, future revisions of the module can add new ‘case’ statements. This solution results in a simple instance encoding, for example:

boot-image-v3.2R1.6.img 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08 ...

What do you think? I’ll assume this is okay If no objections are raised by the end of this week.

Thanks, Kent

netconf-wg / zero-touch

How to verify boot-image integrity? #17