[cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

Peter Gutmann pgut001 at cs.auckland.ac.nz
Sun Dec 4 07:35:25 EST 2011


Lucky Green <shamrock at cypherpunks.to> writes:

>If the concern is that employees receive security warnings when accessing in-
>house websites, the standard solution is to push out a corporate root via AD,
>which is transparent and works quite well.

And once they get AD and/or WSUS ported to OS X and Linux it'll be even more
useful :-).

Another reason I've seen for in-house sub-CAs is that even if you're an all-
Windows environment it may be too hard to push a private root out to everyone
if there's no centralised control over everything (due to
compartmentalisation/chinese walls/geographic distribution/whatever).

>No root CA that I have encountered requires that you operate the HSM in FIPS
>mode or mandates that you shall not back up the private key in the clear to a
>USB flash drive.

I think the reason for the former is that almost no-one ever operates their
hardware in FIPS mode, period.  A few years ago someone who works for $global-
hardware-vendor mentioned at a conference that when you buy their FIPS 140-
certified hardware you need to get an optional add-on, available free for the
asking, to run it in FIPS 140 mode.  In the product's entire lifetime the
number of requests they've had could be counted on the fingers of one hand.

Another global security product vendor shipped one of their flagship products
with a bug that caused it to crash when FIPS 140 mode was enabled.  It took
several years before anyone noticed.

>Every professional services team that I have worked with over the years
>recommended to the customers of such sub-CAs to make a backup of the private
>keys and store them in a safe somewhere. 

PKCS #12 is very popular for this.  Some HSMs, quite reasonably (in the
vendors' view) and quite unreasonably (in the customers' view) don't allow
easy key export except via vendor-supplied mechanisms (e.g. cloning into
another $10,000 HSM or storing key portions in vendor-supplied smart
cards/datakeys/whatever), but if you generate the key in software and load it
into the HSM via a PKCS #12 then you can back it up and share it around
without the HSM getting in the way.

>Sometimes encrypted, sometimes in the clear, but always with the necessary
>decryption information (smartcards and/or PINs) in the same safe.

This is what makes buying crypto gear on eBay so much fun, if you buy PKI-
oriented HSMs then there'll typically be a note stuck to the crypto gear with
the PIN(s) on it.  You end up with all sorts of interesting signing keys that
way (things like Luna CA3's aren't cheap, so only relatively high-value keys
tend to get stored in them, e.g. CA keys for government departments).  As with
disposing of hard drives in PCs and servers, the crypto hardware lifecycle
seems to stop at "we unplugged it".

>The standard sub-CA contracts contain a right to audit the number of certs
>issued, like any enterprise-wide software license agreement does include a
>right to audit used seats. Not once in over 30 years have I seen such an
>audit performed.

Yup, that's what I've found as well, it's just a variation on the per-seat
software licensing model, except that there's no BSA.

>The smart purchasing manager will pay less than USD 50k.

Oh, maybe I've been talking to less smart managers :-), the figures I heard
started at $50K and quickly went up into six digits.  Or maybe the inevitable
race to the bottom has made things cheaper in the last few years.

Peter.



More information about the cryptography mailing list