Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Michael Richardson <mcr+ietf@sandelman.ca> Mon, 12 August 2019 22:30 UTC
Return-Path: <mcr+ietf@sandelman.ca>
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 A42EB120ADE; Mon, 12 Aug 2019 15:30:05 -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 IFs66mlK-wqO; Mon, 12 Aug 2019 15:30:02 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743531223B9; Mon, 12 Aug 2019 12:30:14 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9A5D33818D; Mon, 12 Aug 2019 15:29:28 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 588DADCB; Mon, 12 Aug 2019 15:30:13 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Benjamin Kaduk <kaduk@mit.edu>, anima@ietf.org
cc: The IESG <iesg@ietf.org>, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org
In-Reply-To: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com>
References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 12 Aug 2019 15:30:13 -0400
Message-ID: <22660.1565638213@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/xZjPtr_tr-xLWusF9C1vC4bXWeM>
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: Mon, 12 Aug 2019 22:30:08 -0000
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 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 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. 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. 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. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [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