Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

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 <[e-mail]> 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