[cabfpub] Definitions of Air Gapped and Offline Systems

[Neil Dunbar]

In the NetSec group, we’re updating the definitions suitable to Root CA systems, so that the definitions are both practical and robust. We’d like to solicit opinions from the broader public list.

In particular, we’re looking at the definitions of “Offline” and “Air Gapped” systems, which apply to the HSMs and controlling computers which form the Root CA certificate systems.

The desired security property is this: the equipment should not facilitate the injection of malicious data into the controlled Root CA system. The attack surface for any component of a Root CA system should be very low, extremely difficult to penetrate and the good state of the system should be demonstrable (and thus auditable) throughout the operational lifespan of the equipment.

Here are the current working definitions:

Air Gapped:  Physically and logically connected,  at the most, only to a single utility network (without physical connectivity to the internet) and connected to no other network.  (requires physical presence or physical proximity).

Tobias Josefowitz suggested this alternative:

Air Gapped: Physically and logically disconnected from all other networks, interaction of any kind requires physical presence in proximity. If the system is built of several components, network technology may be used to connect them as long as network equipment and all systems connected are themselves otherwise Air Gapped.

and for Offline:

Offline State: A Certificate System or component that is not available via any external connection (e.g. powered down or unplugged)

The notion being that a Root CA system should ideally be in both Air Gapped and Offline when not in active use.

Now, there are all sorts of notions about components being in known good state, and being not amenable to contagion while in operation and so on, but for the moment we want to concentrate on how to show that your Root CA system upholds the principle of being Air Gapped (and perhaps normally Offline). It was pointed out, for instance, that even having a Wifi kernel module active in a component (not connected to an AP) could still be a vector for attack because of weaknesses in firmware, exploitable via beacon broadcasts. Clearly, then, merely saying “Oh yes, this laptop could do Wifi, but we just don’t" is not enough - it’s still in a potentially bridged state, and therefore not Air Gapped. You would need to ensure that the EFI/BIOS and kernel did not activate the Wifi adapter in the boot sequence.

So - can we get some improvements to the definitions which are:

a) robust, i.e., not amenable to someone using excessive lawyer parsing to say that an architecture technically obeys the rules, but which in reality violate the security property
b) practical, i.e., that can be built and operated within a reasonable commercial operation, and have the salient properties demonstrated to an auditor; and that auditor could faithfully represent that the system under test does indeed adhere to the requirements?

Thanks,

Neil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170908/ca137810/attachment-0002.html>