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 <[email protected]> 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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
