on 06-Nov-2017 04:00
Building a certificate authority (CA) for your lab environment is a pain. Until recently I relied on Jamielinux's OpenSSL Certificate Authority but it slowly lost relevance due to evolutions in Public Key Infrastructure (PKI) requirements, specifically ECC, hash, critical certificate extensions, and revokation changes. This guide adheres to current PKI needs namely RFC 5759 NSA's Suite B Certificate and Certificate Revocation List (CRL) Profile. Before you start burning effigies in the comment section, yes I know ECC curves NIST P-256 and NIST P-384 are not considered "secure" by SafeCurves related to rigidity1, ladder2, completeness3, and indistinguishability4. Modern PKI ends up being a slightly religious debate divided across admins who practice provable security versus evangelists preaching mathematically absolute cryptography. I err towards the side of practical and provable security. If we adjusted cryptological practices to comply with every cryptographic sermon, we'd have nothing left to provide our infrastructure that a reasonable number of clients could connect to; forget if my infrastructure can even support it.
What Suite B does offer is compatibility with browsers and applications. Complying with popular standards allows us to learn about some of the more overlooked PKI requirements mentioned above. You don't need to fully understand the mathematical intricacies of elliptical curves but you do need to know what your applications and clients can use, especially when certain internet entities quietly drop support for unpopular curves "cough.... Chrome". So many caveats to PKI raise a question of why we're using OpenSSL and why are we building a CA compliant to NSA Suite B (specifically NIST P-384).
I tested this series against OpenSSL v1.0.2g (default on Ubuntu 16.04 LTS), and v1.1.0f (manual upgrade to OpenSSL current release). There are some featuers within OpenSSL I am eagerly waiting but are not available as of the current public release. I will keep updating this as requirements and feature become mainstream. This guide is not intended for the hemmoraging edge admin who lives a brazen alpha code lifestyle.
This guide assists the reader to build a lab-ready CA using elliptical curves for cryptographic signatures and hash functions. RFC 5759 states:
This guide uses a common and recommended best practiced two-tier PKI hierarchy certificate authority. A two-tier certificate authority consists of:
This guide is also designed for lab environments because it do not follow recommended security practices for root CA protection or private key protection. More sensitive or public CA's should follow recommended security practices by storing root certificate and key offline or in an IT security-owned HSL (both recommended options for certificate and key protection). Using a dedicated lab CA reduce the exposure of corporate internal resources and limits risk impact to a small subset of machines and should not compromise sensitive data. As you build CA's in other environments like staging or test environments where corporate data may reside, you should increase the security accordingly.
Let's go build a CA!
(1) NIST P-384 is not considered rigid, instead considered manipulatable. Coefficients generated by hashing the unexplained seed a335926a a319a27a 1d00896a 6773a482 7acdac73. The curve-generation process has a large unexplained input, giving the curve generator a large space of curves to choose from. Consider, for example, a curve-generation process that takes y^2=x^3-3x+H(s) meeting various security criteria, where s is a large random "seed" and H is a hash function. No matter how strong H is, a malicious curve generator can search through many choices of s, checking each y^2=x^3-3x+H(s) for vulnerability to a secret attack; this works if the secret attack applies to (e.g.) one curve in a billion.
(2) NIST P-384 does not apply ladder algorithms (in this case the Montgomery ladder) to compute variations in fixed time, preventing timing and/or power information leakage (side-channel attack). SafeCurves requires curves to support simple, fast, constant-time single-coordinate single-scalar multiplication, avoiding conflicts between simplicity, efficiency, and security. This is not a requirement specifically to use Montgomery curves: there are other types of curves that support simple, fast, constant-time ladders. "Fast" means that implementations of scalar multiplication for the same curve cannot be much faster, and "simple" means that reasonably fast implementations of scalar multiplication for the same curve cannot be much more concise. At this time there are no examples close enough to the edge to warrant quantification of "much".
(3) NIST P-384 does not complete single or multi-scalar formulas. SafeCurves requires curves to support simple, fast, complete, constant-time single-coordinate single-scalar multiplication. This includes the SafeCurves ladder requirement but goes further by requiring completeness. SafeCurves also requires curves to support simple, fast, complete, constant-time multi-scalar multiplication.
(4) NIST P-384 does not support indistinguishability. SafeCurves note: "Elligator 2" works for any odd prime and any curve of the form y^2=x^3+Ax^2+Bx with nonzero AB(A^2-4B). This includes all Montgomery curves y^2=x^3+Ax^2+x except for one curve y^2=x^3+x. It also includes, after conversion, all Edwards curves x^2+y^2=1+dx^2y^2 except for one curve x^2+y^2=1-x^2y^2. More generally, it includes all curves with points of order 2, except for j-invariant 1728. Standard representations of elliptic-curve points are easily distinguishable from uniform random strings. This poses a problem for many cryptographic protocols using elliptic curves: censorship-circumvention protocols, for example, and password-authenticated key-exchange protocols.