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
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
