[Servercert-wg] Ballot SC40v3: Security Requirements for Air-Gapped CA Systems

Mon Mar 8 18:13:17 UTC 2021

Of those, the first definition (server + direct-attached HSM) seems not to be blocked by the definition, if we’re including both the server and its HSM as one “CA system”. (That is, the “CA system” consists of one server plus HSM.) The language might need tweaking to specifically allow that and under what circumstances (for example, the HSM must be directly connected via dedicated cable). Considering the two as a pair would seem to also eliminate any possibility of trying to have an online server but an “offline” HSM, too: all parts of the CA required to perform issuance tasks must either be considered online or offline.

The second one would arguably be problematic, yes. Just off the cuff, I’ve seen at least these three configurations in various (non-BR-involved!) contexts:
I have a single offline server-plus-HSM pair that is capable of operating CAs foo, bar, baz, and quux. The keys for all four CAs are stored offline in the HSM, but I only activate and utilize one CA at a time, enforced by the hardware activation mechanisms of the HSM. (Thus, if I am busy performing operations on CA foo, it is not possible to perform any PKI operations on CA quux, and so forth.) All four CAs are physically isolated from the outside, and are also isolated from each other in the HSM, but there is a common set of OS and CA files in use.
I have a single offline server-plus-HSM set with a common OS, but all of the files for the CA are kept on a removable disk and checked into a safe when not in use, while the keys are only stored in any form in the HSM when the CA is in use and then wiped after. Now the isolation is stronger thanks to unique CA files as well as HSM isolation, but you still have a shared OS platform. (And you could extend this model further to a diskless system in which I simply insert the disks for each CA, to create complete system-level isolation for each one, just on a common hardware platform.) 
I have four offline CAs, each of which have their own server, but which share a common network-based HSM. The whole environment is physically air-gapped from any outside connections and the CAs are logically isolated, but each has network access to a common HSM (perhaps via a common “dumb” switch). The whole ecosystem thus exists in a physically air-gapped bubble, but the isolation of the CA servers from each other becomes a matter of logical protections rather than physical.

All of these are things that people will commonly refer to as an “offline CA”, but there are definitely shades of grey when it comes to how much real isolation is occurring. Which of those we want to permit or not permit would be the question.

-- 
Jos Purvis (jopurvis at cisco.com)
.:|:.:|:. cisco systems | Cryptographic Services
PGP: 0xFD802FEE07D19105 | Controls and Trust Verification

From: Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf of CABF Server Cert WG <servercert-wg at cabforum.org>
Reply-To: Wendy Brown - QT3LB-C <wendy.brown at gsa.gov>, CABF Server Cert WG <servercert-wg at cabforum.org>
Date: Monday, March 8, 2021 at 12:44 PM
To: Ryan Sleevi <sleevi at google.com>
Cc: CABF Server Cert WG <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Ballot SC40v3: Security Requirements for Air-Gapped CA Systems

no - I am suggesting in both cases these configurations are for offline CAs but seem to contradict the first clause of the proposed definition: A system that is (a) physically and logically separated from all other CA systems

1) an OFFLINE & Air-gapped CA that uses a network HSM - BOTH the CA server & the HSM are only connected to each other and both powered off, except when needed to be powered on to do some function like sign or revoke a cert or issue a CRL

or 

2) again hardware dedicated only to the operation of OFFLINE & Air-gapped CAs, but potentially hosting multiple offline/Air-gapped CAs on the same hardware, operated by the same trusted roles - not co-mingling with anything considered online or connected to any supporting systems that have to be online
Wendy

Wendy Brown
Supporting GSA FPKI
Protiviti Government Services

 703-965-2990 (cell)

wendy.brown at gsa.gov
wendy.brown at protiviti.com

On Mon, Mar 8, 2021 at 12:19 PM Ryan Sleevi <sleevi at google.com> wrote:

On Mon, Mar 8, 2021 at 9:07 AM Wendy Brown - QT3LB-C via Servercert-wg <servercert-wg at cabforum.org> wrote:

I'm not sure I agree with the first clause of the definition:  A system that is (a) physically and logically separated from all other CA systems

for 2 reasons:  

1) if the CA uses an HSM server, it should be able to be connected to the HSM when turned on as long as the HSM is powered off when the CA is and not connected to any other systems

When would this scenario be used? It seems somewhat dangerous - for example, if the CA system is considered online, but the HSM considered offline (even though physically connected, simply powered off), it seems like there's new threat models to consider (e.g. if the CA system can send a WoL packet to wake up the HSM system). So I'm trying to understand a bit more about what scenario this would be useful for, since it sounds like there's concern that the proposed language would prevent that scenario, to figure out how to resolve that.

2) Why would it not be reasonable to have the same hardware host VMs for multiple offline CAs all operated by the same trusted roles? Or some CA software can support multiple CAs (such as Red Hat, Unicert, and PrimeKey/EJBCA).  Multiple CAs running on the same platform, that is offline, should be considered offline, even though they are not physically separate from each other.

I'm not sure I understand this second point. Are you suggesting that a CA running on such a system could have one CA configuration offline, and another CA configuration online? Or one CA configuration that is considered airgapped running on the same machine/software as another CA configuration that is not?

Neither of those sound like good things to me, and I don't think it'd be what you'd be suggesting. I *think* in such scenarios we want the same outcome: namely, if you bring such a system online (whether a device with multiple VMs or a server instance with multiple CAs), the point at which one is online should be considered the point in which all are online, and the same obligations occur regarding configuration state expectations. Is that a correct understanding?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210308/5d469812/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3699 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210308/5d469812/attachment-0001.p7s>