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

[Michael Richardson <[e-mail]>]

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 

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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-