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

"Max Pritikin (pritikin)" <> Tue, 01 November 2016 22:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30F37129A24 for <>; Tue, 1 Nov 2016 15:15:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -16.018
X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9VNWzf_QKrVK for <>; Tue, 1 Nov 2016 15:15:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77C041299E0 for <>; Tue, 1 Nov 2016 15:15:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4266; q=dns/txt; s=iport; t=1478038552; x=1479248152; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=MxL1W6ZfYQvzGb8MMl5ziX3shY9bG+iCFIz7tkkeSLI=; b=KpJcLz+e2fVdXiZ+Oj778Cihb5U9gxkBJOZqEuQQVhBMmfp4QrRc0TH6 xKQlQeoKIdnVq9dpVyy7QZ4C/7xjSTYF3TyZVWqiNjI+WxN5EvecKwhhf dHZyqZM4+cdDbFfbK5SS6DjMDUoAcxp8TDvBXaL3zxSDNhzr3XrFFpjte c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.31,433,1473120000"; d="scan'208";a="342951159"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Nov 2016 22:15:51 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id uA1MFpVD005846 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Nov 2016 22:15:51 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 1 Nov 2016 17:15:51 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Tue, 1 Nov 2016 17:15:50 -0500
From: "Max Pritikin (pritikin)" <>
To: Toerless Eckert <>
Thread-Topic: [Anima-bootstrap] brsky concern2: Timelyness of log entries
Thread-Index: AQHSNH6Wyy772h1kaEqodWL4RS7jOaDFBdUA
Date: Tue, 01 Nov 2016 22:15:50 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: Toerless Eckert <>, "" <>
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: Tue, 01 Nov 2016 22:15:54 -0000

> On Nov 1, 2016, at 2:28 PM, Toerless Eckert <> wrote:
> -> Attacker has physical access to pledge at some point in time.
> -> Makes device generate nonce messages. Stashes messages away (not connecting
>   to MASA).
> -> 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).
> -> Attacker at some point uses stashed nonce messages to extract audit-logs
>   (and vouchers) from MASA. Can not use them because attacker does not have
>   access to device anymore, but would rase red flags when actual owner
>   of devices would do any new re-enrollment where it looks at audit-log.

I think this conversation could quickly get derailed by the flow details from above (I disagree with some of your assumptions). Perhaps it would help to start with a statement of the security concern you’re raising. I think it is: 

Can an attacker inject entries into the audit log that would cause problems for the Registrar heuristic/analytics based decisions?

The following are attempts to minimize possible attacks against the audit log:

1) Nonced entries require the attacker to have had access to the device during that boot of the device to use the audit token. If the Registrar is comfortable with the chain of control they can ignore these entries. Previous versions have indicated that Registrar authentication by the MASA is required for these as well but I’m not seeing that currently 

2) Nonceless entries are always problematic. From -04: "If a nonce is not provided then the MASA service MUST authenticate the Registrar as a valid customer.  This prevents denial of service attacks” and “the Registrar MUST be authenticated by the MASA service although no requirement is implied that the MASA associates this authentication with ownership.”. I’ve contended that doing so is why we’d have a voucher format indicating ownership. 

Also note that Section 6.4 directly discusses this issue.

A race condition is discussed in the Security Considerations section. 

> I am not sure how strong/likely this attack vector is given how the manufacturer
> can identify and therefore hopefully track down the attackers registrar (given
> that that requires an authenticated ID with the MASA), but:
> The log-entry makes everybody easily believe that the device was having the
> enrollment sgnaling at the time when it was logged when in reality that is
> not true. Yes, it would require up to one more round-trip to establish that
> fact, but it looks prudent to me if that was done.

Section 5.1 includes an EDNOTE to discuss this case. As of yet folks haven’t responded but I’ll take it that you’re voting for this additional round trip.

- max

> Cheers
>    Toerless
> _______________________________________________
> Anima-bootstrap mailing list