Re: [Anima-bootstrap] brsky concern2: Timelyness of log entries

Michael Richardson <> Sat, 12 November 2016 02:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B5F59129545 for <>; Fri, 11 Nov 2016 18:56:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k5TzaZesePWu for <>; Fri, 11 Nov 2016 18:56:34 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C116129536 for <>; Fri, 11 Nov 2016 18:56:34 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTPS id 15FA61F906 for <>; Sat, 12 Nov 2016 02:56:33 +0000 (UTC)
Received: by (Postfix, from userid 179) id 68D2E321D; Fri, 11 Nov 2016 21:56:30 -0500 (EST)
From: Michael Richardson <>
In-reply-to: <>
References: <>
Comments: In-reply-to Toerless Eckert <> message dated "Tue, 01 Nov 2016 21:28:56 +0100."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
X-Attribution: mcr
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Sat, 12 Nov 2016 11:56:30 +0900
Message-ID: <>
Archived-At: <>
Subject: Re: [Anima-bootstrap] brsky concern2: Timelyness of log entries
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 12 Nov 2016 02:56:36 -0000

Toerless Eckert <> wrote:
    > Device gets later enrolled/installed later by valid owner.  Maybe
    > valid owner does re-enroll devices several times, eg: between them
    >    being put into different locations (as often requered in big
    > customers, eg: CPE and the like).

I'm concerned here.
Why would they enroll it multiple times?  This doesn't make sense to me.
If they really wanted to reset to factory default, wouldn't they reflash
completely back to factory, so:

           "Attacker has physical access to pledge at some point in time."

becomes irrelevant?  Was there a TPM? Did the attacker get access to that?
Did they get access to the manufacturer installed private key?

If they didn't really reset to factory default, then it seems that they would
use the LDevID from the first enrollment to rekey with a new LDevID.

So, this is my problem with this scenario.