Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Wed, 14 August 2019 14:53 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A13120921; Wed, 14 Aug 2019 07:53:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9psXf0f3CjoR; Wed, 14 Aug 2019 07:53:10 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 647BD120913; Wed, 14 Aug 2019 07:53:10 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7EEqxYA005733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 10:53:01 -0400
Date: Wed, 14 Aug 2019 09:52:58 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: anima@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org
Message-ID: <20190814145258.GX88236@kduck.mit.edu>
References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <22660.1565638213@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <22660.1565638213@localhost>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/Oqb7JXUfer5Y-H_I16GTcekKHwg>
Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Aug 2019 14:53:14 -0000
On Mon, Aug 12, 2019 at 03:30:13PM -0400, Michael Richardson wrote: > > WG: there is a chunk of Security Considerations text here that I hope > many will read. > > > Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote: > > Section 11.4 > > > It is not entirely clear to me whether device manufacturers are set up > > with incentives to maintain a well-run secure CA with strong hardware > > protections on the offline signing key for the root CA, cycling through > > various levels of intermediates, etc., that CAs in the Web PKI do > > today. If the manufacturer uses a less stringent process, that would > > leave the manufacturer's key as a more tempting attack surface, and it > > may be worth some discussion here about what damage could be done with > > a compromised MASA signing key. E.g., would an attack require > > restoring devices to factory defaults or otherwise waiting for natural > > bootstrapping events to occur? Would the attacker need to be on-path? > > Etc. > > I wanted to add that I think that there are some interesting economic > discussions about these incentives. I wonder how to interest some people > into doing some analysis of a monetary rather that technical manner. > > I have added: > 11.4. Manufacturer Maintenance of trust anchors . . . . . . . 75 > 11.4.1. Compromise of Manufacturer IDevID signing keys . . . 77 > 11.4.2. Compromise of MASA signing keys . . . . . . . . . . 77 > 11.4.3. Compromise of MASA web service . . . . . . . . . . . 79 > > and this text is rough, and as yet unreviewed by anyone, and I (not sure if there was supposed to be much more to that sentence). It's rough, sure, but generally looks quite good in terms of content coverage. > 11.4. Manufacturer Maintenance of trust anchors > > BRSKI depends upon the manufacturer building in trust anchors to the > pledge device. The voucher artifact which is signed by the MASA will > be validated by the pledge using that anchor. This implies that the > manufacturer needs to maintain access to a signing key that the > pledge can validate. > > The manufacturer will need to maintain the ability to make signatures > that can be validated for the lifetime that the device could be > onboarded. Whether this onboarding lifetime is less than the device > > lifetime depends upon how the device is used. An inventory of > devices kept in a warehouse as spares might not be onboarded for many > decades. > > There are good cryptographic hygiene reasons why a manufacturer would > not want to maintain access to a private key for many decades. A > manufacturer in that situation can leverage a long-term certificate > authority anchor, built-in to the pledge, and then a certificate > chain may be incorporated using the normal CMS certificate set. This > may increase the size of the voucher artifacts, but that is not a > significant issues in non-constrained environments. > > There are a few other operational variations that manufacturers could > consider. For instance, there is no reason that every device need > have the same set of trust anchors pre-installed. Devices built in > different factories, or on different days, or any other consideration > could have different trust anchors built in, and the record of which > batch the device is in would be recorded in the asset database. The > manufacturer would then know which anchor to sign an artifact > against. > > Aside from the concern about long-term access to private keys, a > major limiting factor for the shelf-life of many devices will be the > age of the cryptographic algorithms included. A device produced in > 2019 will have hardware and software capable of validating algorithms > common in 2019, and will have no defense against attacks (both > quantum and von-neuman brute force attacks) which have not yet been > invented. This concern is orthogonal to the concern about access to > private keys, but this concern likely dominates and limits the > lifespan of a device in a warehouse. If any update to firmware to > support new cryptographic mechanism were possible (while the device > was in a warehouse), updates to trust anchors would also be done at > the same time. > > The set of standard operating proceedures for maintaining high value > private keys is well documented. For instance, the WebPKI provides a > number of options for audits at {{cabforumaudit}}, and the DNSSEC > root operations are well documented at {{dnssecroot}}. > > It is not clear if Manufacturers will take this level of precaution, > or how strong the economic incentives are to maintain an appropriate > level of security. > > This next section examines the risk due to a compromised MASA key. > This is followed by examination of the risk of a compromised > manufacturer IDevID signing key. The third section sections below > examines the situation where MASA web server itself is under attacker > control, but that the MASA signing key itself is safe in a not- > directly connected hardware module. > > 11.4.1. Compromise of Manufacturer IDevID signing keys > > An attacker that has access to the key that the manufacturer uses to > sign IDevID certificates can create counterfeit devices. Such > devices can claim to be from a particular manufacturer, but be > entirely different devices: Trojan horses in effect. > > As the attacker controls the MASA URL in the certificate, the > registrar can be convinced to talk to the attackers' MASA. The > Registrar does not need to be in any kind of promiscuous mode to be > vulnerable. > > In addition to creating fake devices, the attacker may also be able > to issue revocations for existing certificates if the IDevID > certificate process relies upon CRL lists that are distributed. > > There does not otherwise seem to be any risk from this compromise to > devices which are already deployed, or which are sitting locally in > boxes waiting for deployment (local spares). The issue is that (That is, if the boxes are already in local storage at the time of first compromise) > operators will be unable to trust devices which have been in an > uncontrolled warehouse as they do not know if those are real devices. > > 11.4.2. Compromise of MASA signing keys > > There are two periods of time in which to consider: when the MASA key > has fallen into the hands of an attacker, and after the MASA > recognizes that the key has been compromised. > > 11.4.2.1. Attacker opportunties with compromised MASA key > > An attacker that has access to the MASA signing key could create > vouchers. These vouchers could be for existing deployed devices, or > for devices which are still in a warehouse. In order to exploit > these vouchers two things need to occur: the device has to go through > a factory default boot cycle, and the registrar has to be convinced > to contact the attacker's MASA. > > If the attacker controls a Registrar which is visible to the device, > then there is no difficulty in delivery of the false voucher. A > possible practical example of an attack like this would be in a data > center, at an ISP peering point (whether a public IX, or a private > peering point). In such a situation, there are already cables > attached to the equipment that lead to other devices (the peers at > the IX), and through those links, the false voucher could be > delivered. The difficult part would be get the device put through a > factory reset. This might be accomplished through social engineering > of data center staff. Most locked cages have ventilation holes, and > possibly a long "paperclip" could reach through to depress a factory > reset button. Once such a piece of ISP equipment has been > compromised, it could be used to compromise equipment that was > connected to (through long haul links even), assuming that those > pieces of equipment could also be forced through a factory reset. > > The above scenario seems rather unlikely as it requires some element > of physical access; but were there a remote exploit that did not > cause a direct breach, but rather a fault that resulted in a factory > reset, this could provide a reasonable path. > > The above deals with ANI uses of BRSKI. For cases where 802.11 or > 802.15.4 is involved, the need to connect directly to the device is > eliminated, but the need to do a factory reset is not. Physical > possession of the device is not required as above, provided that > there is some way to force a factory reset. With some consumers > devices with low overall implementation quality, the end users might > be familiar with needing to reset the device regularly. > > The authors are unable to come up with an attack scenario where a > compromised voucher signature enables an attacker to introduce a > compromised pledge into an existing operator's network. This is the > case because the operator controls the communication between > Registrar and MASA, and there is no opportunity to introduce the fake > voucher through that conduit. This seems predicated on the attacker having the MASA signing key but not persistent control of the (formerly?) legitimate MASA service, right? > 11.4.2.2. Risks after key compromise is known > > Once the operator of the MASA realizes that the voucher signing key > has been compromised it has to do a few things. > > First, it MUST issue a firmware update to all devices that had that > key as a trust anchor, such that they will no longer trust vouchers > from that key. This will affect devices in the field which are > operating, but those devices, being in operation, are not performing > onboarding operations, so this is not a critical patch. > > Devices in boxes (in warehouses) are vulnerable, and remain > vulnerable until patched. An operator would be prudent to unbox the > devices, onboard them in a safe environment, and then perform > firmware updates. This does not have to be done by the end-operator; > it could be done by a distributor that stores the spares. A > recommended practice for high value devices (which typically have a > <4hr service window) may be to validate the device operation on a > regular basis anyway. > > If the onboarding process includes attestations about firmware > versions, then through that process the operator would be advised to > upgrade the firmware before going into production. Unfortunately, > this does not help against situations where the attacker operates > their own Registrar (as listed above). > > [RFC8366] section 6.1 explains the need for short-lived vouchers. > The nonce guarantees freshness, and the short-lived nature of the > voucher means that the window to deliver a fake voucher is very > short. A nonceless, long-lived voucher would be the only option for > the attacker, and devices in the warehouse would be vulnerable to > such a thing. > > A key operational recommendation is for manufacturers to sign > nonceless, long-lived vouchers with a different key that they sign > short-lived vouchers. That key needs significantly better > protection. If both keys come from a common trust-anchor (the > manufacturer's CA), then a compromise of the manufacturer's CA would > be a bigger problem. (probably some wordsmithing options for "be a bigger problem") > 11.4.3. Compromise of MASA web service > > An attacker that takes over the MASA web service has a number of > attacks. The most obvious one is simply to take the database listing > customers and devices and to sell this data to other attackers who > will now know where to find potentially vulnerable devices. > > The second most obvious thing that the attacker can do is to kill the > service, or make it operate unreliably, making customers frustrated. > This could have a serious affect on ability to deploy new services by > customers, and would be a significant issue during disaster recovery. > > While the compromise of the MASA web service may lead to the > compromise of the MASA voucher signing key, if the signing occurs > offboard (such as in a hardware signing module, HSM), then the key > may well be safe, but control over it resides with the attacker. > > Such an attacker can issue vouchers for any device presently in > service. Said device still needs to be convinced to do through a > factory reset process before an attack. > > If the attacker has access to a key that is trusted for long-lived > nonceless vouchers, then they could issue vouchers for devices which > are not yet in service. This attack may be very hard to verify and > as it would involve doing firmware updates on every device in > warehouses (a potentially ruinously expensive process), a > manufacturer might be reluctant to admit this possibility. Thanks for writing this up! -Ben
- [Anima] Benjamin Kaduk's Discuss on draft-ietf-an… Benjamin Kaduk via Datatracker
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Adam Roach
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- [Anima] What does PKIX refer to: Re: Benjamin Kad… Michael Richardson
- Re: [Anima] What does PKIX refer to: Re: Benjamin… Michael Richardson
- Re: [Anima] What does PKIX refer to: Re: Benjamin… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- [Anima] Change of authors for draft-ietf-anima-bo… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Adam Roach
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Anima] {FINAL} Benjamin Kaduk's Discuss on d… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson