Building an OpenSSL Certificate Authority - Creating Your Root Certificate
Creating Your Root Certificate Authority In our previous article, Introductions and Design Considerations for Eliptical Curveswe covered the design requirements to create a two-tier ECC certificate authority based on NSA Suite B's PKI requirements. We can now begin creating our CA's root configuration. Creating the root CArequires us to generate a certificate and private key,since this is the first certificate we're creating, it will be self-signed. The root CA will not sign client and server certificates, it's job it only to create intermeidary certificates and act as the root of our chain of trust. This is standard practice across the public and private PKI configurations and so too should your lab environments. Create Your Directory Structure Create a directory to store your root CA pair and config files. # sudo bash # mkdir /root/ca Yep, I did that. This is for a test lab and permissions may not match real world requirements. I sudoed into bash and created everything under root; aka playing with fire. This affects ownership down the line if you chmod private key files and directoriesto user access only so determine for yourself what user/permission will be accessing files for certificate creation. I have a small team and trust them with root within a lab environment (snapshots allow me to be this trusting). Create your CA database to keep track of signed certificates # cd /root/ca # mkdir private certs crl # touch index.txt # echo 1000 > serial We begin by creating a working root directory with sub directories for the various files we'll be creating. This will allow you to apply your preferred security practices should you choose to do so. Since this is a test lab and I am operating as root, I won't be chmod'ing anything today. Create Your OpenSSL Config File OpenSSLuses configuration files to simplify/template the components of a certificate. Copy the GIST openssl_root.cnf file to /root/ca/openssl_root.cnf which is already prepared for this demo. For the root CA certificate creation, the [ CA ] section is required and will gather it's configuration from the [ CA_default ] section. [ ca ] # `man ca` default_ca = CA_default The [CA_default] section in the openssl_root.cnf file contains the variables OpenSSL will use for the root CA. If you're using alternate directory names from this demo, update the file accordingly. Note the long values for default days (10 years) as we don't care about renewing the root certificate anytime soon. [ CA_default ] # Directory and file locations. dir = /root/ca certs = $dir/certs crl_dir = $dir/crl new_certs_dir = $dir/certs database = $dir/index.txt serial = $dir/serial RANDFILE = $dir/private/.rand # The root key and root certificate. private_key = $dir/private/ca.cheese.key.pem certificate = $dir/certs/ca.cheese.crt.pem # For certificate revocation lists. crlnumber = $dir/crlnumber crl = $dir/crl/ca.cheese.crl.pem crl_extensions = crl_ext default_crl_days = 3650 # SHA-1 is deprecated, so use SHA-2 or SHA-3 instead. default_md = sha384 name_opt = ca_default cert_opt = ca_default default_days = 3650 preserve = no policy = policy_strict For the root CA, we define [policy_strict] which will later force the intermediary's certificateto match country, state/province, and organization name fields. [ policy_strict ] The root CA should only sign intermediate certificates that match. # See POLICY FORMAT section of `man ca`. countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional The [ req ] section is used for OpenSSL certificate requests. Some of the values listed will not be used since we are manually specifying them during certificate creation. [ req ] # Options for the `req` tool (`man req`). default_bits = 4096 distinguished_name = req_distinguished_name string_mask = utf8only # SHA-1 is deprecated, please use SHA-2 or greater instead. default_md = sha384 # Extension to add when the -x509 option is used. x509_extensions = v3_ca I pre-populate the [ req_distinguished_name ] section with values I'll commonly used to save typing down the road. [ req_distinguished_name ] countryName = Country Name (2 letter code) stateOrProvinceName = State or Province Name localityName = Locality Name 0.organizationName = Organization Name organizationalUnitName = Organizational Unit Name commonName = Common Name emailAddress = Email Address # Optionally, specify some defaults. countryName_default = US stateOrProvinceName_default = WA localityName_default = Seattle 0.organizationName_default = Grilled Cheese Inc. organizationalUnitName_default = Grilled Cheese Root CA emailAddress_default = grilledcheese@yummyinmytummy.us The [ v3_ca ] section will further define the Suite B PKI requirements, namely basicConstraints and acceptable keyUsage values for a CA certificate. This section will be used for creating the root CA's certificate. [ v3_ca ] # Extensions for a typical CA (`man x509v3_config`). subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true keyUsage = critical, digitalSignature, cRLSign, keyCertSign Selecting the Suite B compliant elliptical curve We're creating a Suite B infrastructure so we'll need to pick an acceptable curve following P-256 or P-384. To do this, run the following OpenSSLcommand: openssl ecparam -list_curves This will give you a long list of options but which one to pick? Let's isolate the suites within the 256 & 384 prime fields; we can grep the results for easier curve identification. openssl ecparam -list_curves | grep '256\|384' And we get the following results (your results may vary depending on the version of OpenSSL running): # openssl ecparam -list_curves | grep '256\|384' secp256k1 : SECG curve over a 256 bit prime field secp384r1 : NIST/SECG curve over a 384 bit prime field prime256v1: X9.62/SECG curve over a 256 bit prime field brainpoolP256r1: RFC 5639 curve over a 256 bit prime field brainpoolP256t1: RFC 5639 curve over a 256 bit prime field brainpoolP384r1: RFC 5639 curve over a 384 bit prime field brainpoolP384t1: RFC 5639 curve over a 384 bit prime field I am going to use secp384r1 as my curve of choice. It's good to mention that RFC5480 notes secp256r1 (not listed) is referred to as prime256v1 for this output's purpose. Why not use something larger than 384? Thank Google. People absolutely were using secp521r1 then Google dropped support for it (read Chromium Bug 478225 for more). The theoryis since NSA Suite B PKI did not explicitly call out anything besides 256 or 384, the Chromium team quietly decided it wasn't needed and dropped support for it. Yea... it kinda annoyed a few people. So to avoid future browser issues, we're sticking with what's defined in public standards. Create the Root CA's Private Key Using the names defined in the openssl_root.cnf's private_key value and our selected secp384r1 ECC curve we will create and encrypt the root certificates private key. # openssl ecparam -genkey -name secp384r1 | openssl ec -aes256 -out private/ca.cheese.key.pem read EC key writing EC key Enter PEM pass phrase: ****** Verifying - Enter PEM pass phrase: ****** Note:The ecparam function within OpenSSL does not encrypt the private key like genrsa/gendsa/gendh does. Instead we combined the private key creation (openssl ecparam) with a secondary encryption command (openssl ec) to encrypt private key before it is written to disk. Keep the password safe. Create the Root CA's Certificate Using the new private key, we can now generate our root'sself-signed certificate. We do this because the root has no authority above it to request trust authority from;it is the absolute source of authority in our certificate chain. # openssl req -config openssl_root.cnf -new -x509 -sha384 -extensions v3_ca -key private/ca.cheese.key.pem -out certs/ca.cheese.crt.pem Enter pass phrase for private/ca.cheese.key.pem: ****** You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [US]: State or Province Name [WA]: Locality Name [Seattle]: Organization Name [Grilled Cheese Inc.]: Organizational Unit Name [Grilled Cheese Root CA]: Common Name []:Grilled Cheese Root Certificate Authority Email Address [grilledcheese@yummyinmytummy.us]: Using OpenSSL we can validate the Certificate contents to ensure we're following the NSA Suite B requirements. # openssl x509 -noout -text -in certs/ca.cheese.crt.pem Certificate: Data: Version: 3 (0x2) Serial Number: ff:bd:f5:2f:c5:0d:3d:02 Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us Validity Not Before: Aug 22 23:53:05 2017 GMT Not After : Aug 20 23:53:05 2027 GMT Subject: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:a6:b7:eb:8b:9f:fc:95:03:02:20:ea:64:7f:13: ea:b7:75:9b:cd:5e:43:ca:19:70:17:e2:0a:26:79: 0a:23:2f:20:de:02:2d:7c:8f:62:6b:74:7d:82:fe: 04:08:38:77:b7:8c:e0:e4:2b:27:0f:47:01:64:38: cb:15:a8:71:43:b2:d9:ff:ea:0e:d1:c8:f4:8f:99: d3:8e:2b:c1:90:d6:77:ab:0b:31:dd:78:d3:ce:96: b1:a0:c0:1c:b0:31:39 ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Subject Key Identifier: 27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB X509v3 Authority Key Identifier: keyid:27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign Signature Algorithm: ecdsa-with-SHA384 30:65:02:30:77:a1:f9:e2:ab:3a:5a:4b:ce:8d:6a:2e:30:3f: 01:cf:8e:76:dd:f6:1f:03:d9:b3:5c:a1:3d:6d:36:04:fb:01: f7:33:27:03:85:de:24:56:17:c9:1a:e4:3b:35:c4:a8:02:31: 00:cd:0e:6c:e0:d5:26:d3:fb:88:56:fa:67:9f:e9:be:b4:8f: 94:1c:2c:b7:74:19:ce:ec:15:d2:fe:48:93:0a:5f:ff:eb:b2: d3:ae:5a:68:87:dc:c9:2c:54:8d:04:68:7f Reviewing the above we can verify the certificate details: The Suite B Signature Algorithm: ecdsa-with-SHA384 The certificate date validity when we specificed -days 3650: Not Before: Aug 22 23:53:05 2017 GMT Not After : Aug 20 23:53:05 2027 GMT The Public-Key bit length: (384 bit) The Issuer we defined in the openssl_root.cnf: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority The Certificate Subject, since this is self-signed, refers back to itself: Subject: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority The eliptical curve used when we created the private key: NIST CURVE: P-384 Verify the X.509 v3 extensions we defined within the openssl_root.cnf for a Suite B CA use: X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign The root certificate and private key are now compete and we have the first part of our CA complete. Step 1 complete! In our next article we willcreate the intermediary certificate to complete the chain of trust in our two-tier hierarchy.Building an OpenSSL Certificate Authority - Creating Your Intermediary Certificate
Creating Your Intermediary Certificate Authority Previously we created the first part of our OpenSSL CA by building our root certificate. We are now ready to complete our CA chain by creating and signing the intermediary certificate.The intermediary will beresponsible for signing client and server certificate requests. It acts as an authoritative proxy for the root certificate hence the name intermediary. The chain of trust will extend from the root certificate to the intermediary certificate down to the certificates you'll deploy within your infrastructure. Create your directory structure Create a new subdirectory under /root/ca to segregate intermediary files our root configuration . # sudo bash # mkdir /root/ca/intermediate We're creating the same directory structure previously used under /root/ca within /root/ca/intermediary . It's your decision if you if you want to do something different. Some of my best friends are flat directory structures and we don't judge personal practices. Create your intermediary CA database to keep track of signed certificates # cd /root/ca/intermediate # mkdir certs crl csr private # touch index.txt # echo 1000 > serial Create a crlnumber file for the intermediary CA to use # echo 1000 > /root/ca/intermediate/crlnumber Similar to the earlier serial statement, this will create the crlnumber file and start the numerical iteration at 1000. This will be used for future certificate revocation needs. Create your OpenSSL intermediary config file Copy the GIST openssl_intermediate.cnf file to /root/ca/intermediate/openssl_intermediate.cnf and modify the contents for your own naming conventions. Similar to the root_ca.cnf , the [CA] is required and will gather it's configuration from the [CA_default] section. Changes to the [int_ca] include: [ CA_default ] # Directory and file locations. dir = /root/ca/intermediate private_key = $dir/private/int.cheese.key.pem certificate = $dir/cers/int.cheese.crt.pem crlnumber = $dir/crlnumber crl = $dir/crl/int.cheese.crl.pem crl_extensions = crl_ext policy = policy_loose We have new certificate names for our intermediary use and define policy_loose so future certificate requests don't have to match country, state/province, or organization. Create the Intermediary's Private Key and Certificate Signing Request Similar to the root certificate, we're following the NSA Suite B requirements and matching the root's elliptical curve, secp384r1. We'll alsocreate the CSR and private key all in one line, making your scripts and life a bit easier. # cd /root/ca # openssl req -config intermediate/openssl_intermediate.cnf -new -newkey ec:<(openssl ecparam -name secp384r1) -keyout intermediate/private/int.cheese.key.pem -out intermediate/csr/int.cheese.csr Generating an EC private key writing new private key to 'intermediate/private/int.cheese.key.pem' Enter PEM pass phrase: ****** Verifying - Enter PEM pass phrase: ****** ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [US]: State or Province Name [WA]: Locality Name [Seattle]: Organization Name [Grilled Cheese Inc.]: Organizational Unit Name [Grilled Cheese Intermediary CA]: Common Name []:Grilled Cheese Inc. Intermediary Certificate Authority Email Address [grilledcheese@yummyinmytummy.us]: Sign the certificate request with the root certificate and use the openssl_intermediate.cnf config file to specify the [v3_intermediate_ca] extension instead of the [v3_ca] as we did for the root. The openssl_intermediate.cnf has a few changes which we need to note. [ v3_intermediate_ca ] # Extensions for a typical intermediate CA (`man x509v3_config`). subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer basicConstraints = critical, CA:true, pathlen:0 keyUsage = critical, digitalSignature, cRLSign, keyCertSign crlDistributionPoints = @crl_info authorityInfoAccess = @ocsp_info [crl_info] URI.0 = http://crl.grilledcheese.us/whoremovedmycheese.crl [ocsp_info] caIssuers;URI.0 = http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP;URI.0 = http://ocsp.grilledcheese.us/ The Certificate Revocation List (crl) and Online Certificate Status Protocol (OCSP) should be included within the intermediary certificate. This lets systems know where check and see if the intermediary certificate was revoked by the root at any given time. We will cover this in detail later and browsers do not necessarily check the intermediary certificates for revocation, but they absolutely do for the site certificates. We're adding CRL and OCSP to the Intermediary CA for best practices purpose. Create the intermediate certificate Sign the csr/int.cheese.cs r with the root's certificate. We are going to drop down to /root/ca so the creation of the intermediary certificate is stored within the root's index.txt and we'll also use the root's OpenSSL Config file openssl_root.cnf . # openssl ca -config openssl_root.cnf -extensions v3_intermediate_ca -days 3600 -md sha384 -in intermediate/csr/int.cheese.csr -out intermediate/certs/int.cheese.crt.pem Using configuration from openssl_root.cnf Enter pass phrase for /root/ca/private/ca.cheese.key.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 4097 (0x1001) Validity Not Before: Aug 24 21:51:07 2017 GMT Not After : Jul 3 21:51:07 2027 GMT Subject: countryName = US stateOrProvinceName = WA organizationName = Grilled Cheese Inc. organizationalUnitName = Grilled Cheese Intermediary CA commonName = Grilled Cheese Inc. Intermediary Certificate Authority emailAddress = grilledcheese@yummyinmytummy.us X509v3 extensions: X509v3 Subject Key Identifier: 7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD X509v3 Authority Key Identifier: keyid:27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ Certificate is to be certified until Jul 3 21:51:07 2027 GMT (3600 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated Validate the Certificate Contents with OpenSSL. # openssl x509 -noout -text -in intermediate/certs/int.cheese.crt.pem Certificate: Data: Version: 3 (0x2) Serial Number: 4097 (0x1001) Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Root CA, CN = Grilled Cheese Inc. Root Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us Validity Not Before: Aug 24 21:51:07 2017 GMT Not After : Jul 3 21:51:07 2027 GMT Subject: C = US, ST = WA, O = Grilled Cheese Inc., OU = Grilled Cheese Intermediary CA, CN = Grilled Cheese Inc. Intermediary Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:9b:14:9a:55:6d:db:15:7f:d7:8b:fd:37:4d:ba: e8:50:8e:88:32:99:27:4e:20:36:25:8b:7b:ac:bb: 2f:d6:61:c1:5a:c8:e6:4c:98:20:3f:cf:86:3c:bf: f4:f3:b0:1c:1c:0b:cc:7f:e4:4b:13:59:58:a1:53: 87:cb:4c:17:66:04:21:01:6a:44:5f:22:31:7d:3d: fe:a2:e7:73:c8:77:7c:1a:f9:9c:4a:9d:e7:77:6a: c7:9e:3e:f0:4a:b0:37 ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Subject Key Identifier: 7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD X509v3 Authority Key Identifier: keyid:27:C8:F7:34:2F:30:81:97:DE:2E:FC:DD:E2:1D:FD:B6:8F:5A:AF:BB X509v3 Basic Constraints: critical CA:TRUE, pathlen:0 X509v3 Key Usage: critical Digital Signature, Certificate Sign, CRL Sign X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ Signature Algorithm: ecdsa-with-SHA384 30:65:02:30:74:07:ba:fe:4b:71:78:d8:d2:7f:84:c0:50:b4: b6:df:6c:f6:57:f5:d9:2c:4b:e1:d4:d8:1d:78:fd:7e:bf:0a: 81:86:bb:40:c5:9b:97:6f:83:04:5f:d3:85:36:6c:d6:02:31: 00:d3:08:78:1c:da:6d:ef:1d:bb:27:df:0b:76:eb:ab:84:b2: 91:04:25:1a:85:5b:d5:c3:cd:66:e4:9e:14:b2:c0:ed:9c:59: b7:18:c3:26:eb:df:78:13:68:47:66:b5:43 Similar to the root, we can note the usage and algorithms but we have the addition of: * X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl *Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ Create the certificate chain The root certificate and intermediary certificate must be available to the requesting client/server in order to validate the chain of trust. To complete the trust validation, a certificate chain must be available to the client application. A certificate chain usually takes the form of separate certificates installed into Root and Intermediary containers (as the case for Windows), or bundled together either in a .pfx cert and certchain bundle or a PEM formatted text file. Concatenate the root and intermediate certificates together to create a PEM certificate chain text file. # cd /root/ca # $cat intermediate/certs/int.cheese.crt.pem certs/ca.cheese.crt.pem > intermediate/certs/chain.cheese.crt.pem The file should look similar to this with two separate BEGIN and END statements for each certificate (example condensed for space): # cat intermediate/certs/chain.cheese.crt.pem -----BEGIN CERTIFICATE----- MIID/TCCA4OgAwIBAgICEAEwCgYIKoZIzj0EAwMwgdQxCzAJBgNVBAYTAlVTMQsw CQYDVQQIDAJXQTEQMA4GA1UEBwwHU2VhdHRsZTEcMBoGA1UECgwTR3JpbGxlZCBD ...... hkjOPQQDAwNoADBlAjB0B7r+S3F42NJ/hMBQtLbfbPZX9dksS+HU2B14/X6/CoGG u0DFm5dvgwRf04U2bNYCMQDTCHgc2m3vHbsn3wt266uEspEEJRqFW9XDzWbknhSy wO2cWbcYwybr33gTaEdmtUM= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDQTCCAsegAwIBAgIJAP+99S/FDT0CMAoGCCqGSM49BAMDMIHUMQswCQYDVQQG EwJVUzELMAkGA1UECAwCV0ExEDAOBgNVBAcMB1NlYXR0bGUxHDAaBgNVBAoME0dy ...... CgYIKoZIzj0EAwMDaAAwZQIwd6H54qs6WkvOjWouMD8Bz4523fYfA9mzXKE9bTYE +wH3MycDhd4kVhfJGuQ7NcSoAjEAzQ5s4NUm0/uIVvpnn+m+tI+UHCy3dBnO7BXS /kiTCl//67LTrlpoh9zJLFSNBGh/ -----END CERTIFICATE----- Note: In the real world hosting application should never have the entire chain available as it defeats a core principle of PKI. It's recommended in test labs to distribute the root certificate to all testing client applications and systems and include only the intermediary along with the server certificate. This way the client can establish the trust between the intermediary and root certificates. Next we'll move on to creating our CLR endpoint list and OCSP certificate. Our intermediary certificate is now created and signed and we are ready to move on. To complete the CAour next articlewe will create our certificate revocation list (CRL) endpointand online certificate status protocol (OCSP) certificate allowing us to revoke certificates. Lab environments rarely need revocation functionalitybut modern clients check for CLR and OCSP URIs so it's nessisary to have the configruation defined at minimum. Let's proceed.
Implementing ECC+PFS on LineRate (Part 1/3): Choosing ECC Curves and Preparing SSL Certificates
(Editors note: the LineRate product has been discontinued for several years. 09/2023) --- Overview In case you missed it,Why ECC and PFS Matter: SSL offloading with LineRatedetails some of the reasons why ECC-based SSL has advantages over RSA cryptography for both performance and security. This article will generate all the necessary ECC certificates with the secp384r1 curve so that they may be used to configure an LineRate System for SSL Offload. Getting Started with LineRate In order to appreciate the advantages of SSL/TLS Offload available via LineRate as discussed in this article, let's take a closer look at how to configure SSL/TLS Offloading on a LineRate system. This example will implement Elliptical Curve Cryptography and Perfect Forward Secrecy. SSL Offloading will be added to an existing LineRate System that has one public-facing Virtual IP (10.10.11.11) that proxies web requests to a Real Server on an internal network (10.10.10.1). The following diagram demonstrates this configuration: Figure 1: A high-level implementation of SSL Offload Overall, these steps will be completed in order to enable SSL Offloading on the LineRate System: Generate a private key specifying the secp384r1 elliptic curve Obtain a certificate from a CA Configure an SSL profile and attach it to the Virtual IP Note that this implementation will enable only ECDHE cipher suites. ECDH cipher suites are available, but these do not implement the PFS feature. Further, in production deployments, considerations to implement additional types of SSL cryptography might be needed in order to allow backward compatibility for older clients. Generating a private key for Elliptical Curve Cryptography When considering the ECC curve to use for your environment, you may choose one from the currently available curves list in the LineRate documentation. It is important to be cognizant of the curve support for the browsers or applications your application targets using. Generally, the NIST P-256, P-384, and P-521 curves have the widest support. This example will use the secp384r1 (NIST P-384) curve, which provides an RSA equivalent key of 7680-bits. Supported curves with OpenSSL can be found by running the openssl ecparam -list_curves command, which may be important depending on which curve is chosen for your SSL/TLS deployment. Using OpenSSL, a private key is generated for use with ssloffload.lineratesystems.com. The ECC SECP curve over a 384-bit prime field (secp384r1) is specified: openssl ecparam -genkey -name secp384r1 -out ssloffload.lineratesystems.com.key.pem This command results in the following private key: -----BEGIN EC PARAMETERS----- BgUrgQQAIg== -----END EC PARAMETERS----- -----BEGIN EC PRIVATE KEY----- MIGkAgEBBDD1Kx9hghSGCTujAaqlnU2hs/spEOhfpKY9EO3mYTtDmKqkuJLKtv1P 1/QINzAU7JigBwYFK4EEACKhZANiAASLp1bvf/VJBJn4kgUFundwvBv03Q7c3tlX kh6Jfdo3lpP2Mf/K09bpt+4RlDKQynajq6qAJ1tJ6Wz79EepLB2U40fC/3OBDFQx 5gSjRp8Y6aq8c+H8gs0RKAL+I0c8xDo= -----END EC PRIVATE KEY----- Generating a Certificate Request (CSR) to provide the Certificate Authority (CA) After the primary key is obtained, a certificate request (CSR) can be created. Using OpenSSL again, the following command is issued filling out all relevant information in the successive prompts: openssl req -new -key ssloffload.lineratesystems.com.key.pem -out ssloffload.lineratesystems.com.csr.pem This results in the following CSR: -----BEGIN CERTIFICATE REQUEST----- MIIB3jCCAWQCAQAwga8xCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhDb2xvcmFkbzET MBEGA1UEBxMKTG91aXN2aWxsZTEUMBIGA1UEChMLRjUgTmV0d29ya3MxGTAXBgNV BAsTEExpbmVSYXRlIFN5c3RlbXMxJzAlBgNVBAMTHnNzbG9mZmxvYWQubGluZXJh dGVzeXN0ZW1zLmNvbTEeMBwGCSqGSIb3DQEJARYPYS5yYWdvbmVAZjUuY29tMHYw EAYHKoZIzj0CAQYFK4EEACIDYgAEi6dW73/1SQSZ+JIFBbp3cLwb9N0O3N7ZV5Ie iX3aN5aT9jH/ytPW6bfuEZQykMp2o6uqgCdbSels+/RHqSwdlONHwv9zgQxUMeYE o0afGOmqvHPh/ILNESgC/iNHPMQ6oDUwFwYJKoZIhvcNAQkHMQoTCGNpc2NvMTIz MBoGCSqGSIb3DQEJAjENEwtGNSBOZXR3b3JrczAJBgcqhkjOPQQBA2kAMGYCMQCn h1NHGzigooYsohQBzf5P5KO3Z0/H24Z7w8nFZ/iGTEHa0+tmtGK/gNGFaSH1ULcC MQCcFea3plRPm45l2hjsB/CusdNo0DJUPMubLRZ5mgeThS/N6Eb0AHJSjBJlE1fI a4s= -----END CERTIFICATE REQUEST----- Obtaining a Certificate from a Certificate Authority (CA) Rather than using a self-signed certificate, a test certificate is obtained from Entrust. Upon completing the certificate request and receiving it from Entrust, a simple conversion needs to be done to PEM format. This can be done with the following OpenSSL command: openssl x509 -inform der -in ssloffload.lineratesystems.com.cer -out ssloffload.lineratesystems.com.cer.pem This results in the following certificate: -----BEGIN CERTIFICATE----- MIIC5jCCAm2gAwIBAgIETUKHWzAKBggqhkjOPQQDAzBtMQswCQYDVQQGEwJVUzEW MBQGA1UEChMNRW50cnVzdCwgSW5jLjEfMB0GA1UECxMWRm9yIFRlc3QgUHVycG9z ZXMgT25seTElMCMGA1UEAxMcRW50cnVzdCBFQ0MgRGVtb25zdHJhdGlvbiBDQTAe Fw0xNDA4MTExODQ3MTZaFw0xNDEwMTAxOTE3MTZaMGkxHzAdBgNVBAsTFkZvciBU ZXN0IFB1cnBvc2VzIE9ubHkxHTAbBgNVBAsTFFBlcnNvbmEgTm90IFZlcmlmaWVk MScwJQYDVQQDEx5zc2xvZmZsb2FkLmxpbmVyYXRlc3lzdGVtcy5jb20wdjAQBgcq hkjOPQIBBgUrgQQAIgNiAASLp1bvf/VJBJn4kgUFundwvBv03Q7c3tlXkh6Jfdo3 lpP2Mf/K09bpt+4RlDKQynajq6qAJ1tJ6Wz79EepLB2U40fC/3OBDFQx5gSjRp8Y 6aq8c+H8gs0RKAL+I0c8xDqjgeEwgd4wDgYDVR0PAQH/BAQDAgeAMB0GA1UdJQQW MBQGCCsGAQUFBwMBBggrBgEFBQcDAjA3BgNVHR8EMDAuMCygKqAohiZodHRwOi8v Y3JsLmVudHJ1c3QuY29tL0NSTC9lY2NkZW1vLmNybDApBgNVHREEIjAggh5zc2xv ZmZsb2FkLmxpbmVyYXRlc3lzdGVtcy5jb20wHwYDVR0jBBgwFoAUJAVL4WSCGvgJ zPt4eSH6cOaTMuowHQYDVR0OBBYEFESqK6HoSFIYkItcfekqqozX+z++MAkGA1Ud EwQCMAAwCgYIKoZIzj0EAwMDZwAwZAIwXWvK2++3500EVaPbwvJ39zp2IIQ98f66 /7fgroRGZ2WoKLBzKHRljVd1Gyrl2E3BAjBG9yPQqTNuhPKk8mBSUYEi/CS7Z5xt dXY/e7ivGEwi65z6iFCWuliHI55iLnXq7OU= -----END CERTIFICATE----- Note that the certificate generation process is very familiar with Elliptical Curve Cryptography versus traditional cryptographic algorithms like RSA. Only a few differences are found in the generation of the primary key where an ECC curve is specified. Continue the Configuration Now that the certificates needed to configure Elliptical Curve Cryptography have been created, it is now time to configure SSL Offloading on LineRate. Part 2: Configuring SSL Offload on LineRate continues the demonstration of SSL Offloading by importing the certificate information generated in this article and getting the system up and running. In case you missed it,Why ECC and PFS Matter: SSL offloading with LineRatedetails some of the reasons why ECC-based SSL has advantages over RSA cryptography for both performance and security. (Editors note: the LineRate product has been discontinued for several years. 09/2023) Stay Tuned! Next week a demonstration on how to verify a correct implementation of SSL with ECC+PFS on LineRate will make a debut on DevCentral. The article will detail how to check for ECC SSL on the wire via WireShark and in the browser. In the meantime, take some time to download LineRate and test out its SSL Offloading capabilities. In case you missed any content, or would like to reference it again, here are the articles related to implementing SSL Offload with ECC and PFS on LineRate: Why ECC and PFS Matter: SSL offloading with LineRate Implementing ECC+PFS on LineRate (Part 1/3): Choosing ECC Curves and Preparing SSL Certificates Implementing ECC+PFS on LineRate (Part 2/3): Configuring SSL Offload on LineRate Implementing ECC+PFS on LineRate (Part 3/3): Confirming the Operation of SSL OffloadingBuilding an OpenSSL Certificate Authority - Configuring CRL and OCSP
Certificate Revocation Lists We completed reviewing our PKI design considerations and createdroot and intermediary certificates completeing our two-tier certificate authority. Now we'll createcertificate revocation configurations to comply withNSA Suite B PKI. A certificate revocation list (CRL) is a published list of revoked certificates issued and updated by the certificate authority who signed them. Clients like your internet browser, will check the certificate's CRL URI to find out if the certificate is valid. When a certificate is revoked, the CRL is updated to reflect the revokation and published accordingly. Lists are not the most efficient way to maintain a record of revocation in high volume scenarios so some application vendors have deprecated their use in favor of online certificate status protcol (OCSP). We still needa CRL configuraiton as it's still common and recommended for backward compatibility. Previously we created a CRL URI via the openssl_intermediary.cnf when creating the intermediary certificate. This was an exercise in anticipation of us creating the CRL. Don't forgetwe're adhering to NSA's Suite B PKI so we have to remember: Every Suite B certificate and CRL MUST be signed using ECDSA And certificate and CRL MUST be hashed using SHA-256 or SHA-384, matched to the size of the signing CA's key The OpenSSL configuration file object [ server_cert ] includes crlDistributionPoints = @crl_info which directs the OpenSSL to: [crl_info] URI.0 = http://crl.grilledcheese.us/whomovedmycheese.crl This allows us to enter multiple CRL distribution points for redundancy. Create the CRL # cd /root/ca # openssl ca -config intermediate/openssl_intermediate.cnf -gencrl -out intermediate/crl/whomovedmycheese.crl Using configuration from intermediate/openssl_intermediate.cnf Enter pass phrase for /root/ca/intermediate/private/int.cheese.key.pem: ****** Validate the CRL with OpenSSL # openssl crl -in intermediate/crl/whomovedmycheese.crl -noout -text Certificate Revocation List (CRL): Version 2 (0x1) Signature Algorithm: ecdsa-with-SHA384 Issuer: /C=US/ST=WA/O=Grilled Cheese Inc./OU=Grilled Cheese Intermediary CA/CN=Grilled Cheese Inc. Intermediary Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us Last Update: Aug 24 23:21:38 2017 GMT Next Update: Feb 20 23:21:38 2018 GMT CRL extensions: X509v3 Authority Key Identifier: keyid:7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD X509v3 CRL Number: 4097 No Revoked Certificates. Signature Algorithm: ecdsa-with-SHA384 30:65:02:30:7b:e4:08:01:06:60:c8:e8:c8:fb:a7:e8:49:7b: bf:ee:a6:a6:19:8f:93:67:6c:15:25:bb:c0:d2:ad:c1:ff:05: d4:73:e0:72:f0:35:cd:64:35:8b:83:e7:7c:47:ed:ea:02:31: 00:d4:3c:30:7c:00:73:b6:93:34:3e:1d:96:8f:ba:8a:9b:21: 3e:ff:36:95:2c:e9:6e:e9:4b:9c:6c:49:1d:fd:ba:6a:75:70: 41:a5:5e:67:4d:ca:04:2c:c5:37:46:52:91 Yesit was that easy. The CRL file will reside at the URI you specified within the openssl_intermediary.cnf . Online Certificate Status Protocol The online certificate status protocol (OCSP) is used to check x.509 certificates revocation status. This is the preferred method over CRL by utilizing OCSP responders to return a positive, negative, or unknown status. This provides a faster response for the revocation check versus parsing potentially bulky CRL files. The OCSP responder must be signed by the same CA that issued the certificate being validated. OCSP stapling further improves certificate revocation checking by allowing the server hosting the certificate in question to provide a time-stamped response on behalf of the OCSP responder. Additions to the x.509 v3 extensions would require an OCSP stapled response during TLS negotiation or the connection would be terminated (unless an unknownstatus or no response is returned). Setting up an OCSP responder equires a server with our OCSP certificate in play and is out of scope for this article. OCSP configuration data is already present in our /root/ca/intermediate/openssl_intermediate.cnf so when the intermediary certificate was created, it referenced theconfiguration through the [ v3_intermediate_ca ] extension authorityInfoAccess = @ocsp_info. [ocsp_info] caIssuers;URI.0 = http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP;URI.0 = http://ocsp.grilledcheese.us/ Create the OCSP key & certificate Just like the intermediary CA, we'll generate the key and CSR in one line, using the same secp384r1 elliptical curve during root and intermediary CA creation. # cd /root/ca # openssl req -config intermediate/openssl_server.cnf -new -newkey ec:<(openssl ecparam -name secp384r1) -keyout intermediate/private/ocsp.cheese.key.pem -out intermediate/csr/ocsp.cheese.csr.pem -extensions server_cert Generating an EC private key writing new private key to 'intermediate/private/ocsp.cheese.key.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [US]: State or Province Name [WA]: Locality Name [Seattle]: Organization Name [Grilled Cheese Inc.]: Organizational Unit Name [Grilled Cheese Intermediary CA]: Common Name []:ocsp.grilledcheese.us Email Address [grilledcheese@yummyinmytummy.us]: Sign the CSR with our Intermediary Certificate Authority # openssl ca -config intermediate/openssl_intermediate.cnf -extensions ocsp -days 365 -notext -md sha384 -in intermediate/csr/ocsp.cheese.csr.pem -out intermediate/certs/ocsp.cheese.crt.pem Using configuration from intermediate/openssl_intermediate.cnf Enter pass phrase for /root/ca/intermediate/private/int.cheese.key.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 4103 (0x1007) Validity Not Before: Aug 28 22:23:14 2017 GMT Not After : Aug 28 22:23:14 2018 GMT Subject: countryName = US stateOrProvinceName = WA localityName = Seattle organizationName = Grilled Cheese Inc. organizationalUnitName = Grilled Cheese Intermediary CA commonName = ocsp.grilledcheese.us emailAddress = grilledcheese@yummyinmytummy.us X509v3 extensions: X509v3 Basic Constraints: CA:FALSE X509v3 Subject Key Identifier: 55:96:45:08:3E:BA:6A:F7:1C:A2:5A:4E:5C:BB:63:65:44:8F:DD:4B X509v3 Authority Key Identifier: keyid:7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: critical OCSP Signing Certificate is to be certified until Aug 28 22:23:14 2018 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated Verify the certificate's usage is set for OCSP # openssl x509 -noout -text -in intermediate/certs/ocsp.cheese.crt.pem X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: critical OCSP Signing OCSP Stapling and Beyond OpenSSLdoes support operating as an OCSP responder. Per OpenSSL's OCSP man page, running their OCSP server is benefitial for test and demo purposes and is not recommended forproduction OCSP responder use. Other PKI vendors have more robust OCSP management capabilitiesintegratinginto CMS web solutions. Since most clients carry on with a certificates duty if OCSP is unavailablethis shouldn't concern us for testing purposes. If you want to setup OCSP stapling DevCentral's Jason Rahm has a guide on setting up OCSP Stapling for use within the virtual server interfaces if you're so inclined to enable BIG-IP for these features. Now we've completed a basic CRL and OCSP configuration, our clients (web browsers) shouldn't complain and we can move on to the fun part, creating server certificates!Building an OpenSSL Certificate Authority - Creating ECC Certificates
Creating ECC Certificates Previously on Building an OpenSSL CA, we created a certificate revocation list, OCSP certificate, and updated our OpenSSL configuration file to include revokation URI data. Now we are ready to create our first server certificate and sign them with our fully armed and operational CA. What's becoming a themethere are two caveats to note prior to creating our first server CSR. Stop rolling your eyes and stay with me. Certificates MUST have subjectAltName (SAN) extensions of type DNSName defined 1 . Openssl currently supports population of SubjectAltName through configuration files only, including the current version v1.1.0f (true at guides publication date) 2 . Copy the Gist openssl_server.cnf file to /root/ca/intermediate/openssl_server.cnf and modify the contents for your own naming conventions. The openssl_server.cnf file has new entries at the [server_cert] location to create the subjectAltName field our certificate mentioned in the earlier noted points. This alternative name should matchwhat we enter for the [commonName] field. [ server_cert ] subjectAltName = @alt_names [alt_names] DNS.0 = webby.grilledcheese.us You can add additional names to the certificate by iterating the [alt_names] section. Below is an example of the openssl config formatting for multiple names. Example: [alt_names] DNS.0 = yourdomain.com DNS.1 = sassymolassy.yourdomain.com DNS.2 = *.skeletor.yourdomain.com DNS.3 = *.orco.greyskull.yourdomain.com RFC 5280regarding subject alternative names states no upper bound limit is defined (no limit to how many names you can enter). However there are practical and application limitations so plan your certificate's alternate names wisely and try to match what you would implement in production. You're also thinking, how does this scale for multiple CSRs? It doesn't. You'll need to either update the openssl_server.cnf every time you want to create a new certificate or create a copy for each new certificate. We'll worry about scripting and simplifying that process in another followup article. Create the private key and CSR. Create the private key and CSR and specify either P-256 or P-384 approved curves. Since the root and intermediary CA's use P-384, Suite B allows us to use either. If we created the CA using P-256, we would not be able to use P-384 for the client/server certificate. We also need to ensure our certificate's hash function matches the signing CA, in our case SHA-384. # cd /root/ca # openssl req -config intermediate/openssl_server.cnf -new -newkey ec:<(openssl ecparam -name secp384r1) -keyout intermediate/private/webby.cheese.key.pem -out intermediate/csr/webby.cheese.csr Generating an EC private key writing new private key to 'intermediate/private/webby.cheese.key.pem' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [US]: State or Province Name [WA]: Locality Name [Seattle]: Organization Name [Grilled Cheese Inc.]: Organizational Unit Name [Grilled Cheese Dev Lab]: Common Name []:webby.grilledcheese.us Email Address [grilledcheese@yummyinmytummy.us]: Create the Certificate Use the intermediary certificate to create and sign the CSR for webby.grilledcheese.us. # cd /root/ca # openssl ca -config intermediate/openssl_server.cnf -extensions server_cert -days 730 -in intermediate/csr/webby.cheese.csr -out intermediate/certs/webby.cheese.crt.pem Using configuration from intermediate/openssl_server.cnf Enter pass phrase for /root/ca/intermediate/private/int.cheese.key.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 4104 (0x1008) Validity Not Before: Sep 6 20:10:39 2017 GMT Not After : Sep 6 20:10:39 2019 GMT Subject: countryName = US stateOrProvinceName = WA localityName = Seattle organizationName = Grilled Cheese Inc. organizationalUnitName = Grilled Cheese Dev Lab commonName = webby.grilledcheese.us emailAddress = grilledcheese@yummyinmytummy.us X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server Netscape Comment: Grilled Cheese Generated Server Certificate X509v3 Subject Key Identifier: E0:48:57:7E:F9:92:BA:B9:F9:23:41:8D:3D:85:86:82:25:5C:FC:92 X509v3 Authority Key Identifier: keyid:7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD DirName:/C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Root CA/CN=Grilled Cheese Inc. Root Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us serial:10:01 X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ X509v3 Subject Alternative Name: DNS:webby.grilledcheese.us Certificate is to be certified until Sep 6 20:10:39 2019 GMT (730 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated Validate the certificate # openssl x509 -noout -text -in intermediate/certs/webby.cheese.crt.pem Certificate: Data: Version: 3 (0x2) Serial Number: 4104 (0x1008) Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, ST = WA, O = Grilled Cheese Inc., OU = Grilled Cheese Intermediary CA, CN = Grilled Cheese Inc. Intermediary Certificate Authority, emailAddress = grilledcheese@yummyinmytummy.us Validity Not Before: Sep 6 20:10:39 2017 GMT Not After : Sep 6 20:10:39 2019 GMT Subject: C = US, ST = WA, L = Seattle, O = Grilled Cheese Inc., OU = Grilled Cheese Dev Lab, CN = webby.grilledcheese.us, emailAddress = grilledcheese@yummyinmytummy.us Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:bf:48:5b:9b:b2:e2:cf:de:e6:5a:33:3a:9f:73: 70:82:75:86:bd:6f:6a:98:e6:5e:31:fb:af:c5:9f: 68:dc:8b:bc:24:69:08:d8:35:c9:be:76:d4:3d:c5: 48:b3:8f:f6:fd:4a:b9:75:70:58:2c:65:f5:72:61: 62:b8:58:ae:ba:f1:cc:95:1e:bd:60:b2:18:92:19: d2:c3:fd:60:10:60:5a:ad:e5:29:94:f8:37:1b:5b: e5:41:50:fe:39:b9:1c ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server Netscape Comment: Grilled Cheese Generated Server Certificate X509v3 Subject Key Identifier: E0:48:57:7E:F9:92:BA:B9:F9:23:41:8D:3D:85:86:82:25:5C:FC:92 X509v3 Authority Key Identifier: keyid:7E:2D:A5:D0:9B:70:B9:E3:D2:F7:C0:0A:CF:70:9A:8B:80:38:B1:CD DirName:/C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Root CA/CN=Grilled Cheese Inc. Root Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us serial:10:01 X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ X509v3 Subject Alternative Name: DNS:webby.grilledcheese.us Signature Algorithm: ecdsa-with-SHA384 30:65:02:31:00:b1:ab:4e:4f:21:86:14:12:fe:34:ea:47:00: 67:29:cb:47:70:b2:ad:22:a0:dc:5b:65:7b:22:10:5e:ea:08: 7d:09:8d:c5:77:f5:8b:ff:fa:d2:5b:7a:1e:c6:57:e2:12:02: 30:64:f1:fb:14:ea:cf:b4:20:7d:f3:f5:bc:d0:82:0c:06:03: fc:05:84:5d:f9:37:dc:d6:51:83:7b:8b:f6:91:08:d6:22:4f: 16:96:ff:0a:52:68:47:09:0c:71:90:23:d4 Validation of the webby.cheese.crt.pem file shows the updated x509 fields that define our server certificate: X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Server Netscape Comment: Grilled Cheese Generated Server Certificate The certificate also includes full CRL and OCSP endpoints. X509v3 CRL Distribution Points: Full Name: URI:http://crl.grilledcheese.us/whomovedmycheese.crl Authority Information Access: CA Issuers - URI:http://ocsp.grilledcheese.us/cheddarcheeseroot.crt OCSP - URI:http://ocsp.grilledcheese.us/ And it includes our required subjectAltname. X509v3 Subject Alternative Name: DNS:webby.grilledcheese.us The index.txt file we created for our intermediary certificate now has a new entry. Confirm theCA's database is updated with the newly created certificate. This file will prevent new certificates from being created with the same CN. If you need to recreate the certificate with the same name AND YOU'RE IN A LAB ENVIRONMENT, you can use vi/vim/nano/whatever to delete this line. The production-preferred method is to revoke and reissue. # cat intermediate/index.txt V 180828222314Z 1007 unknown /C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Intermediary CA/CN=ocsp.grilledcheese.us/emailAddress=grilledcheese@yummyinmytummy.us V 190906201039Z 1008 unknown /C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Dev Lab/CN=webby.grilledcheese.us/emailAddress=grilledcheese@yummyinmytummy.us The intermediary certificate was responsible for signing the OCSP certificate and our new server certificate; both are listed in the index.txt file. Lastly we can validate the entire certificate chain using the previously created chain.cheese.crt.pem against our newly created server certificate. # openssl verify -CAfile intermediate/certs/chain.cheese.crt.pem intermediate/certs/webby.cheese.crt.pem intermediate/certs/webby.cheese.crt.pem: OK Deploying Your Certificate Your application or server will usually accept PEM format or a PFX bundle which contains certificate, key and certificate chain (if you desire to). In production environments you would not distribute the root certificate along with the intermediate. Even in lab environments, you should distribute the root certificate independently to clients to simulate real world environments. In production systems all mainstream certificate authorities are packaged with operating systems or independent key stores. The intermediary used should match one of these existing root CAs only... For our example, if you were deploying the PEM formatted files, you would need to provide: webby.cheese.key.pem (our server certificate's private key) webby.cheese.crt.pem (our server certificate) int.cheese.crt.pem or chain.cheese.crt.pem (our intermediary CA's certificate or root and certificate concatenated into one file) If you plan to install the certificate and chain in PFX format: # openssl pkcs12 -export -out intermediate/certs/webby.cheese.pfx -inkey intermediate/private/webby.cheese.key.pem -in intermediate/certs/webby.cheese.crt.pem -certfile intermediate/certs/chain.cheese.crt.pem Enter pass phrase for intermediate/private/webby.cheese.key.pem: ****** Enter Export Password: ****** Verifying - Enter Export Password: ****** Validate the PFX bundle # openssl pkcs12 -info -in intermediate/certs/webby.cheese.pfx Enter Import Password: ****** MAC:sha1 Iteration 2048 PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048 Certificate bag Bag Attributes localKeyID: F7 6B 18 13 DD 04 4E 31 D7 A4 8D AE F5 1F 3B DC AD F3 F8 E8 subject=/C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Dev Lab/CN=webby.grilledcheese.us/emailAddress=grilledcheese@yummyinmytummy.us issuer=/C=US/ST=WA/O=Grilled Cheese Inc./OU=Grilled Cheese Intermediary CA/CN=Grilled Cheese Inc. Intermediary Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us -----BEGIN CERTIFICATE----- MIIFSDCCBM6gAwIBAgICEAgwCgYIKoZIzj0EAwMwgdIxCzAJBgNVBAYTAlVTMQsw .... lv8KUmhHCQxxkCPU -----END CERTIFICATE----- Certificate bag Bag Attributes: no attributes="" subject=/C=US/ST=WA/O=Grilled Cheese Inc./OU=Grilled Cheese Intermediary CA/CN=Grilled Cheese Inc. Intermediary Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us issuer=/C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Root CA/CN=Grilled Cheese Inc. Root Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us -----BEGIN CERTIFICATE----- MIID/TCCA4OgAwIBAgICEAEwCgYIKoZIzj0EAwMwgdQxCzAJBgNVBAYTAlVTMQsw .... wO2cWbcYwybr33gTaEdmtUM= -----END CERTIFICATE----- Certificate bag Bag Attributes: no attributes="" subject=/C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Root CA/CN=Grilled Cheese Inc. Root Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us issuer=/C=US/ST=WA/L=Seattle/O=Grilled Cheese Inc./OU=Grilled Cheese Root CA/CN=Grilled Cheese Inc. Root Certificate Authority/emailAddress=grilledcheese@yummyinmytummy.us -----BEGIN CERTIFICATE----- MIIDQTCCAsegAwIBAgIJAP+99S/FDT0CMAoGCCqGSM49BAMDMIHUMQswCQYDVQQG .... /kiTCl//67LTrlpoh9zJLFSNBGh/ -----END CERTIFICATE----- PKCS7 Data Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048 Bag Attributes localKeyID: F7 6B 18 13 DD 04 4E 31 D7 A4 8D AE F5 1F 3B DC AD F3 F8 E8 Key Attributes: no attributes="" Enter PEM pass phrase: Verifying - Enter PEM pass phrase: -----BEGIN ENCRYPTED PRIVATE KEY----- MIIBEzBOBgkqhkiG9w0BBQ0wQTApBgkqhkiG9w0BBQwwHAQItDjLLd4ozIkCAggA .... GxO/udVd0Bg0zY6eSQV1xyXhGd4GJexnKv/IHeYWjpJMyNqa4O9o -----END ENCRYPTED PRIVATE KEY----- We've completed building a two-tier NSA Suite B certificate authority for use within dev or lab environment. You'll still want to create web services to home the CRL list and act as OCSP Resolvers if you need that level of testing. The big drawback to manually using OpenSSL is the requirement of configuration files for SAN requirements. Manually updating or iterating a new OpenSSL configuration file for each certificate (requiring subjetAltName) is not efficient but I have yet to find a clean script to resolve this. I guess we'll just build one. Later. Notes: (1)The subjectAltNamefieldwas proposed to be preferredinstead of the commonName (CN) field in RFC 2818 by Mozilla's E. Rescorla (who submitted it under his company RTFM, Inc... look up the acronym). No one really knew about it because the RFC also allowed defaulting back to the CN field if no subjectAltName existed. But combined with the seldom read CA/Browser forum's Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates (released April of 2017), the subjectAltName field is now the only field of consequence for defining hostnames or IP's in a certificate. Guess how everyone found about this. Browsers simply removed support for the CN field as the host name and broke everyone's web sites siting "correcting a 17 year old requirement". Fortunately for some of us, our public CA's started auto-populating this field for a several years prior to the browser abandonment and reduced the impact to public sites. However internal CA's were left floundering (unless you read every RFC that comes out and then that doesn't even cover it). Thanks E. Rescorla for your vaugely worded RFC and Google's inability to provide visibility like they did to SHA1 deprecation (with advanced public warning and careful planning). Let's forget that the field is called ALTERNATE NAME... that annoys me at a core level. You have nothing better to do than read every RFC that could potentially affect your life, 17 years down the road... right? (2) OpenSSL Git pull request #341 "Add 'copy and 'move configuration values for DNS Subject Alternative Names" exists in the Post1.1.0 milestone but code commit is still pending into openssl:master branch. So we're stuck with config files for each certificate you want to use for now, unless you want to script it yourselves. Alternativly, OpenSSL has an GIT open Issue #3311 for "Interactivly specify subjecAltName (SAN). Here's to hoping.Real Cryptography Has Curves: Making The Case For ECC
Consider yourself a fascinating person if you've ever heard the term "Elliptic Curve Cryptography" (ECC). Consider yourself a cryptographic crackerjack if you actually know what it does and how it all works. If you are a mere mortal like the rest of us, you might not understand every single aspect of ECC. Nonetheless, many web applications are (or soon will be) using ECC to secure online transactions, so I wanted to spend some time discussing the details behind this relevant and important topic. A Walk Down Memory Lane Before diving into Elliptic Curve Cryptography (ECC), let's take a quick stroll down the cryptography memory lane that brought us to the point of even caring about ECC. Prior to the 1970s, cryptography was based primarily on securing communications using a shared secret key. This secret key was used to both encrypt and decrypt communications. This type of encryption is called “symmetric” because the same key is used to encrypt and decrypt. Symmetric encryption is still used widely today because of its speed and efficiency. In fact, you are using it right now to read this article! As computers grew in popularity and our reliance on secure communications became more and more necessary for everyday life, experts began to see a significant issue with symmetric encryption. This issue dealt with key distribution and exchange. Back in the day, people would have to find creative ways to share the secret encryption/decryption key so that no one else got their hands on it. Imagine the headache of trying to figure out how to share a secret key with someone on the other side of the world. And, what if the key was compromised? How do you re-share a new key? You can see how this could turn into a frustrating situation. Fortunately, in 1977, a new era of viable cryptography was introduced. Rather than dealing with the hassle of distributing symmetric keys, a few really smart dudes introduced what we now know as Public Key Cryptography. In Public Key Cryptography, two keys are used…a private key and a public key. Anyone in the world can get a copy of the public key, but only the user has a copy of his/her private key. The genius of it all is that the private key can decrypt a message that has been encrypted with the public key…in fact, the private key is the ONLY key that can decrypt a message that has been encrypted with the associated public key. Today, we use Public Key Cryptography to share symmetric encryption keys. That way, we can still realize the efficiency and speed of symmetric encryption without the headache of sharing the symmetric keys. Is That A Trapdoor? Public Key Cryptography is awesome because it allows you to literally share half of your encryption key with anyone and everyone. But, the question is…how in the world does that even work? How can you give away half of your encryption information and still have a viable and secure form of communication? The fundamental approach to solving this problem comes in the form and what’s called a “trapdoor” function. A trapdoor function is one that’s really easy to solve in one direction, but really difficult to solve the other direction. For example, if I could create a mathematical function that makes it super easy to get to point “B” given a value for point “A” but makes it almost impossible to figure out where point “A” is if I only know the value of point “B” then I have a good trapdoor function…easy one direction but hard the other. A good trapdoor function is absolutely critical in the implementation of Public Key Cryptography. But that begs another question…do we have any good trapdoor functions lying around? Rivest, Shamir, and Adleman…Oh My! Remember when I talked about that 1977 date? Well, that’s the year that three really smart dudes from MIT described their approach to what has proven to be a very popular and successful Public Key Cryptosystem. The name, RSA, is derived from the first letters of each of their last names (Rivest, Shamir, and Adleman). As it turns out, RSA uses very large prime numbers, along with the “modulo” function, to do its thing. Of course, it gets pretty complicated when you break it all the way down to the crazy details. But the overall idea is that it’s really easy to multiply two random prime numbers together to get a really big number, but it’s really hard to guess the prime factors of the really big number if all you have is the really big number. Everything in RSA starts with two prime numbers (p and q). All other RSA values are derived from calculations based on those two prime numbers. Here’s an explanation of how it all works. Pick two random prime numbers, “p” and “q”. Next, calculate the value for “n” by multiply the two prime numbers together. The value “n” is also called the “modulus” and is also the encryption key size. So, if you use RSA 2048 bit, that means you have chosen two numbers “p” and “q” that, when multiplied together, result in a number that is 2,048 bits in size. That’s a pretty big number! Next, you calculate what’s called the “totient” of n, written as Φ(n). You do that by multiplying p-1 and q-1 together. Stay tuned for more from this value…it will prove to be extremely valuable! Then, you choose a number “e” (also called the “exponent”) that is between 1 and Φ(n). Not only does “e” have to fall between 1 and Φ(n), it also has to be a number whereby the Greatest Common Divisor (GCD) of “e” and Φ(n) is 1. The last thing to do is calculate the ever-important private value. The private value is typically represented by the letter “d” and is determined by calculating the multiplicative inverse of e (modulo φ(n)). The “modulo” or “mod” operation is a math function that finds the remainder value after dividing two numbers together in a division problem. The value for “d” is often found using the Extended Euclidean Algorithm. Once you have the value for “d”, you have all the pieces you need for a fully functional RSA public key cryptosystem! Check out the picture on the right to see the hexadecimal representation of the public key value used for the f5.com website. By the way, if you’ve ever wondered how to decipher that crazy long hexadecimal number into something more readable, check out this post and you’ll see how you can do it. What you’ll find is that the public key hexadecimal number shown in your certificate details actually includes two values…one for “n” and one for “e”. You’ll also find this website useful for converting large hexadecimal numbers to decimal. Did you know? Most applications choose the number 65,537 (0x10001) as the value for “e” As a refresher, the components of the RSA cryptosystem are: p = random prime number q = random prime number n = p * q Φ(n) = (p-1) * (q-1) e = number between 1 and Φ(n) d = e -1 (modulo Φ(n)) Public Key = key pair (e, n) Private Key = key pair (d, n) RSA Encryption… All the pieces are in place, but how do we use them all to do the encrypting and decrypting? To encrypt something using the public key, you start with a plain text value (let’s call it “m”) and then encrypt it using the following math calculation: m e mod n Notice that all we need to encrypt something are the original plain text value and the public key values (e, n). When you complete this calculation, you have magically completed the encryption, and now you have your coveted encrypted value (called cipher text). RSA Decryption… In order to decrypt this cipher text value and get back to the original plain text, you take the cipher text (let’s call it “c”) and complete the following calculation using the private key values (d, n). Notice that you only need the cipher text value and the private key values in order to complete the decryption. It’s also interesting to note that, if this cipher text was derived by anything other than your own public key encryption values, your private key decryption won’t work! c d mod n RSA Working Example… Now that all the pieces are in place and we have the formulas needed to encrypt and decrypt, let’s run through a working example of the RSA public key cryptosystem. We will start with the random prime numbers of 11 and 13. Using all the calculations above, we have: p = 11 q = 13 n = 11 x 13 = 143 Φ(n) = 10 x 12 = 120 e = 7 (it turns out that 7 is between 1 and 120, and the GCD of 7 and 120 is 1…so, it fits all the criteria to be our public key value) d = 7 −1 (mod 120) = 103 The public key is represented by the key pair (7, 143) The private key is represented by the key pair (103, 143) Let’s start with a plain text value of “9” and let’s encrypt it because, you know, it’s super-sensitive information. Using the key values that were generated above, we find that the encrypted value is: 9 7 mod 143 = 48 So, the encrypted value for “9” is “48” using all the RSA numbers we chose above. Obviously, the encrypted values will change given different values for p, q, n, etc. To decrypt the value, we use our handy-dandy decryption formula and find that: 48 103 mod 143 = 9 And, just like that, we are back at our original value of 9. It’s mathematical magic, and I personally think it’s completely fascinating. Looking back on all the math of it, you can see that it’s totally possible to share the values for “e” and “n” without giving away any of the information needed to calculate the private key. That’s because “d” is calculated using the “totient of n” rather than the value for “n” itself. It’s super easy to calculate the “totient of n” (and, thus, the private key) if you have the factors of “n”…and that’s what the entire foundation of the security of RSA is built on. It’s really easy to multiply prime numbers together, but it’s really hard to factor a number into its component primes. In our example, if you were given the number 143 (the value of n), then could you figure out that the prime numbers used to generate that number were 11 and 13? Maybe so, but could you do it if the value for “n” was 2,048 bits long? RSA is still an extremely viable and strong public key cryptosystem, but with the increased power of computers and their ability to crunch through numbers, it’s becoming more necessary to increase the key size in RSA to achieve a usable degree of security. Easily put, if you want more security, increase the key size. That’s all well and good, but it comes at a price. Of course, something has to chunk through all those crazy huge RSA numbers, and it has to do it every time you establish a secure connection (which is pretty much all the time nowadays). Let’s say you have a large population of mobile device users…do you think their smartphones are custom-built to handle the intense calculations needed for large RSA key sizes? Probably not. What if there was a way to use much smaller key sizes but keep the same level of security? Lucky for you (and everyone else), there is… What is Elliptic Curve Cryptography? Elliptic Curve Cryptography (ECC) is a public key cryptosystem much like RSA in that it is used as the mechanism to create a public key and a private key in order to encrypt/decrypt data. While RSA is founded on the mathematical difficulty of factoring prime numbers, ECC is based on the mathematical difficulty of solving what is called the elliptic curve discrete logarithm problem. I’ll get into more detail on what that is, but it essentially deals with the problem of knowing how many steps it takes to move from one point on an elliptic curve to another point on that curve. Turns out, even if you know the equation for the curve and the point to start hopping around the curve, you can be presented with another point on the curve and still have no idea how many hops it took to get from the starting point to the point you were just presented with. Pretty crazy, huh? That’s the difficulty of the elliptic curve discrete logarithm problem, and that’s what the entire security of ECC is built on. To understand this “hopping around the curve”, let’s begin with a few interesting characteristics about elliptic curves as well as a concept known as Point Addition. Elliptic curves have symmetry about the x-axis, and any non-vertical line will intersect the curve in at most 3 points. The elliptic curves used in cryptography today are typically defined by the following algebraic function: y 2 = x 3 + ax + b The variables x and y are the standard variables used in any algebraic function and are used to define the points on the x-axis and y-axis on a standard graph. The curve parameters a and b are coefficient values (constant numbers) that define what the curve will actually look like on a graph. As the values for a and b change, the graph will take on a different look when it is graphed. Here’s one example of an elliptic curve on a graph. This particular graph has the values a = -6 and b = 10. y 2 = x 3 – 6x + 10 Point Addition is an operation on an elliptic curve that allows you to start with one point and ultimately arrive at another point on the curve. Here’s how Point Addition works: given two points on the curve (P and Q), draw a straight line through them and intersect the curve at a third point (called -R). Then, follow the value for -R along a vertical line until you intersect the curve again. This intersecting point is the value for R. So, P+Q = R … you just have to find -R first in order to ultimately find the value for R. Once you have the value for R, you can then draw a line from P to R and you’ll find that the line intersects the graph again at a third point. You can then take that point and move along a vertical line until you intersect the graph again. This becomes the Point Addition for points P and R. You can continue this Point Addition as many times as you need. The graph below shows an example of Point Addition: Another operation used in ECC is called Point Doubling. Point Doubling is similar to Point Addition except that in point doubling, you add P to itself rather than add P to another point on the curve. When you have two different points on the elliptic curve (P and Q), it’s easy to draw a straight line between them, but when you only have one point, how do you draw a straight line so that it intersects with another point on the curve? The answer is to draw the tangent line to the point (P) and then let the tangent line intersect the curve at another point. At the intersecting point, you follow along a vertical line until you intersect the curve again (exactly the same concept as the P + Q operation above). At that intersecting point, you find the value for P + P. The Point Doubling operation is shown on the graph below. Notice that the resulting value for P + P is labeled R. This resultant point is also commonly referred to as 2P. In order to find the value for 3P, though, you go back to the Point Addition operation and add P + 2P. Then, to find 4P, you use Point Addition again to add P + 3P, and so on… Point Addition and Point Doubling are important because they form the basis for finding values that are used for encryption using ECC. They also highlight the basis for the Elliptic Curve Discrete Logarithm Problem that was mentioned above. This problem states that, given point P and Q where Q is a multiple of P…find k such that Q = kP. In other words, continue to Point Double/Point Add P a random number of times to land on a point on the curve. Then, knowing the starting point P and the current point on the curve, tell how many times you Point Doubled/Point Added in order to get from P to the current point. It sounds fairly straightforward, but it turns out to be extremely difficult. And, it’s the one way function needed for the basis of using ECC for public key encryption. One other important characteristic of the elliptic curve is the concept of a finite field. Imagine, as you continue to Point Double/Point Add on the elliptic curve, that some of the points will land at a very large value on the x-axis. In reality, you can’t allow every single value to be included in your calculations (you can’t go all the way out to infinity), so the way to limit these values is to establish a “max” value on the x-axis. This value is represented as “p” in the ECC cryptosystem, and it is also called the “modulo” value for the system. Effectively, it defines the finite field that the curve is defined over. This value is also the key size for the ECC system. Many ECC implementations choose a prime number for “p” thus making them a “prime” curve. As you increase the value for “p” then you open up the possibilities for more usable values on the curve, and you effectively increase the security of the system using that particular curve. That’s why an increased key size results in a more secure curve. Now that we know all this goodness, let’s go over the values you need in order to fully define the ECC cryptosystem. These are: Curve equation : y 2 = x 3 +ax + b p: Specifies the finite field that the curve will be defined over (modulo value) a: Coefficient that defines the curve b: Coefficient that defines the curve G: Generator point on the curve. This is the point where all the Point operations begin. n: Order of G. The number of Point operations on the curve until the resultant line is vertical. h: Cofactor – the number of points on the elliptic curve divided by the order of G (ideally this value is 1 or very close to 1) All of these values are known in advance. In fact, for a given elliptic curve used for encryption today, you’ll want to choose a curve and all the associated values based on recommendations from the really smart mathematicians and scientists who have worked all these values out and tested them thoroughly for their use in encryption. In other words, don’t define your own elliptic curve and expect it to be secure. Diffie Hellman Using ECC Now that we know all the ECC parameters, let’s walk through the implementation of ECC using the Diffie Hellman key exchange protocol. Imagine that Alice wants to establish a secure connection with Bob and she chooses ECC Diffie Hellman as the mechanism to exchange encryption keys. First, Alice will choose a random number between 1 and n-1. We will call it ⍺. At the same time, Bob is choosing a random number between 1 and n-1 as well. We’ll call Bob’s value β. Now we have: ⍺: randomly chosen number between 1 and n-1. This is the private key for Alice β: randomly chosen number between 1 and n-1. This is the private key for Bob Next, Bob computes the value B = β (G). Bob can compute this value because he knows the values for β and G. At the same time, Alice computes A = ⍺ (G). Alice can compute this value because she knows the values for ⍺ and G. Next, Bob sends Alice the point on the curve (x B , y B ), and Alice sends Bob the point on the curve (x A , y A ). These two points on the curve are the public key values for Bob and Alice. Still, neither person knows the other person’s private key value (⍺ or β). They only know A and B (public keys) because they were sent those respective points on the curve. A malicious eavesdropper would have all the values except for ⍺ and β (the private keys). While a man in the middle could verify that A and B are points on the given elliptic curve, he would not know how many hops the points are from the initial generator point (G). He would need the value for ⍺ or β to know the number of hops. Again, this is the foundation of the Elliptic Curve Discrete Logarithm Problem. Next, Bob and Alice then compute the value P by multiplying their respective private key value by the value received by the other person. So, Bob computes: P = β * A or, substituting ⍺ (G) for A, you get P = β * ⍺ * G Alice computes: P = ⍺ * B or, substituting β (G) for B, you get P = ⍺ * β * G Now, Bob and Alice both have the point P that they can use as their symmetric key encryption value! A Working Example… Let’s take all this goodness and actually work through an example with real numbers! Keep in mind, the values for this curve and all the other associated parameters have been worked out in advance. This curve uses very small numbers for p and n, so you wouldn’t want to use this specific curve in real life. Here are the values for our ECC cryptosystem using the Diffie Hellman key exchange protocol: Curve: y 2 = x 3 + 2x + 2 (mod 17) p: 17 (notice this is a prime number, so this is considered a “prime” curve) a: 2 b: 2 G: (5,1) n: 19 To find n, you Point Double/Point Add starting from G until you reach a point at infinity. That is, the operations continue until the resultant line is vertical. In this case, n = 19. Here are the first few operations for this particular curve; starting at the Generator Point (5,1): 2G = G + G = (6,3) Note: this point is found using Point Doubling 3G = 2G + G = (10,6) Note: the remaining points are found using Point Addition 4G = 3G + G = (3,1) … 19G = h = 1 (which is the ideal value for h) Now we are ready to start computing values for ⍺ and β. Alice picks a value for ⍺. The value for ⍺ must be between 1 and n-1 (18). ⍺ = 3 Next, Alice computes the value for A: A = ⍺ * G = 3G A = (10,6) Note: compare this point 3G to the 3G point listed above in the calculations for “n”. This is how you know what point is represented by 3G. Notice that the value for A is not a single number. Rather, it is the point on the curve represented by Point Doubling/Point Addition operations conducted ⍺ times. Bob picks a value for β. The value for β must be between 1 and n-1 (18). β = 9 B = β * G = 9G B = (7,6) They share the values A and B with each other and are then ready to both compute the value for P. Bob computes P = β * A = β * 3G = 9 * 3G = 27G. Because the order of the curve (n) is 19, 27G reduces to 8G. If the value for P results in a number higher than the order of the curve, you use the modulo operation to find the resulting value. In this example, 27 mod 19 = 8. So, 27G becomes 8G because 27 is larger than 19. Alice computes P = ⍺ * B = ⍺ * 9G = 3 * 9G = 27G. Alice uses the same logic as Bob in reducing 27G to 8G. So, P = 8G = (13,7) Now, Bob and Alice both have the point (13,7) as their shared secret, and the man in the middle has no idea what the value for P is. They don’t need to use both the x-value and the y-value, so they can just throw away one of the values (let’s say they throw away the y-value). Now, they have the value 13 as a shared secret and they can use this to encrypt all further communication. Why Is ECC So Popular? ECC provides a way of exchanging encryption keys (which is hugely necessary on the Internet these days), and it does it much more efficiently than RSA. This allows for lower CPU utilization, less memory usage, faster key generation, faster certificate processing, etc. The following table shows a comparison between RSA key sizes and ECC key sizes that provide the same level of security. Notice a couple of things. First, the key size for ECC is significantly smaller than that of RSA for the equal level of security. Second, the key size for RSA gets proportionately much larger as increased strength is needed compared to ECC. For example, if you want triple the level of security for RSA, you have to triple the key size (1024 to 3072). But, for ECC if you want triple the level of security, you only have to increase the key size by 1.6 times (160 to 256). These are the primary reasons ECC is so desirable in web application security today. RSA Key Size ECC Key Size 1024 160 2048 224 3072 256 7680 384 15360 512 Real Life Curves Remember how I mentioned that you shouldn’t create an elliptic curve on your own because it probably wouldn’t actually be secure and efficient? Well, the good news is that other really smart people have already created a bunch of curves for you. The National Institute of Standards and Technology (NIST) has developed five recommended “prime” curves called: p192, p224, p256, p384, and p521. Other curves are also recommended by Certicom in the Standards for Efficient Cryptography (SEC2) in which the curves are named secp192r1, secp224r1, secp256r1, secp384r1, secp521r1. With any of these curves, a good random number generator is needed to provide proper security. It’s interesting to me that all these curves and sophisticated cryptography is in place only to fully rely on the need for a quality random number generator. Be sure your cryptosystem is using a good one! What Curves Are Supported By F5? Currently, F5 provides support for curves p256 and secp384r1. But, other curves are in the process of being supported with future version releases. BIG-IP supports ECC for use in the Digital Signature Algorithm and Diffie Hellman key exchange protocols. For more info on how to configure SSL ciphers, check out our WhiteBoard Wednesday video on SSL Ciphers. Also, check out our Lightboard Lesson video on ECC to see a graphical presentation on all this goodness. Well, that’s it. Now you can get out there and get crazy with all that ECC!Building an OpenSSL Certificate Authority - Introduction and Design Considerations for Elliptical Curves
Introduction Building a certificate authority (CA) for your lab environment is a pain. Until recently I reliedon 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. Thisguide adheres tocurrent PKI needs namelyRFC 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 rigidity 1 , ladder 2 , completeness 3 , and indistinguishability 4 . ModernPKI 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). OpenSSL is free and used by a majority of OS and application vendors. Many admins have familiarity with it's various commands My lab is in AWS and their provided Active Directory offerings do not allow us Enterprise Admin roles; a requirement for setting up Microsoft Certificate Authorities and I am not going to spin up independent AD infrastructure for isolated VPCs We learn OpenSSL commands related to elliptical curves (some of the many) We must pay attention to certificate extension attributes We must create a revocation policy which many existing guides gloss over We must pay attention to OpenSSL's caveat's and limitations to modern PKI requirements, including version support for various features. 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. Suite B PKI Requirements and CA Design Considerations This guide assists the reader to build a lab-ready CA using elliptical curves for cryptographic signatures and hash functions.RFC 5759 states: Every Suite B cert MUST use the x.509 v3 format and contain An ECDSA-capable signing key, using curves P-256 or P-384 OR An ECDH-capable key establishment key, using curve P-256 or P-384 Every Suite B certificate and CRL MUST be signed using ECDSA. The CA's (Root and Intermediary) MUST be on the curve P-256 or P-384 if the CA contains a key on the curve P-256. If the certificate contains a key on the curve P-384, the signing CA's Key MUST be on the curve P-384. Any certificate and CRL MUST be hashed using SHA-256 or SHA-384, matched to the size of the signing CA's key. Suite B PKI follows RFC5280 for marking extensions as critical and non critical. Microsoft helps distill the extension requirements to: subjectKeyIdntifier (SKI), keyUsage, and basicConstraints MUST exist keyUsage MUST be marked as critical keyCertSign and CRLSign MUST be set All other bits (with exceptions for digital signature and non-repudiation) MUST NOT BE SET This guide uses a common and recommended best practiced two-tier PKI hierarchy certificate authority. A two-tier certificate authority consists of: A self-signed root certificate An intermediary certificate signed by the root (completing the two tiers of the certificate authority) A CRL distribution point and OCSP Resolver URI for the intermediary and subsequent client & server certificates (allowing the root to revoke an intermediary certificate) Client and server certificates signed by the intermediary certificate 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 storingroot certificate and key offline orin an IT security-ownedHSL (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! Notes: (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.Lightboard Lessons: Elliptic Curve Cryptography
You've seen our Whiteboard Wednesday videos, but we are kicking it up a notch and introducing our new "Lightboard Lessons" video series. In this first video, John talks about the basics of Elliptic Curve Cryptography (ECC). ECC has been around for a while and it's gaining popularity as a viable alternative to RSA. But what exactly is ECC? And what are some of the key benefits it provides in protecting your web applications? Watch this video and find out! Resources BIG-IP Support for Elliptic Curve Cryptography Associating Multiple SSL Cert/Key Pair Types with an SSL Profile LogJams, DHE Parameters, and Other Obstacles to TLS Excellence Supporting Elliptic Curve Cryptography Stronger Keys and Faster Security with ECC We hope you enjoy this series of Lightboard Lessons, and stay tuned for many more exciting videos! Clarification: During my quick explanation of RSA, I said that two prime numbers are multiplied together to produce a really big prime number (at 2:20 - 2:25 in the video). As we all know, a prime number only has itself and 1 as factors. So, if you multiply two numbers together, the resultant number will at least have the two numbers you multiplied as factors…thus not making it prime. Technically speaking, the product of the two prime numbers in RSA is called a “semiprime” number because its only factors are 1, itself, and two prime numbers. Here’s a more detailed explanation of semiprimes: https://en.wikipedia.org/wiki/Semiprime For each RSA number "n", there exist prime numbers “p” and “q” such that n = p × q The problem is to find these two primes, given only n. The salient point for RSA is that “n” will always be semiprime. All that said, I should have said “a really big semiprime number” in the video, but I didn’t want to take up too much time discussing RSA since this video is targeted for ECC.
Stronger Keys and Faster Security with ECC
#infosec #linerate Really fast crypto in software on commodity hardware is possible after all. Anyone who has been involved with security knows there is a balance to providing both security and privacy and performance at the same time. Security is often blamed for performance woes, particularly when cryptography is involved. SSL and TLS have long addressed this balance by leveraging custom-built hardware to enhance the performance of the most taxing components of these protocols: session setup. The "easy" part of securing communications (if one can use easy with respect to cryptography) is bulk encryption. While certainly more taxing on performance than clear text, relative to the more complex and compute intensive process of the handshaking required to set up such sessions, easy is an appropriate term. Moore's Law is often cited as providing the increases in computer power necessary to offset the performance tax imposed by secure protocols. Unfortunately while this would be true if all other factors remained constant, the reality is that other factors are also changing and impose additional burdens on the protocol that often negate the gains made by Moore's Law. Key lengths, for example, continue to grow to combat the increase in compute power that makes it easier to brute-force crack a cryptographic key and new challenges with respect to privacy are changing the frequency with which those keys are generated.. There are also occasionally leaps in the mathematic realm that find ways to more quickly compute the “hard problem” that the cryptographic algorithm uses, but those are rare and don’t march at the steady pace that compute power increases do. PFS (Perfect Forward Secrecy), for example, has been offered as a way to combat potential snooping by third-parties (read: governments) by requiring the generation of ephemeral (short lived) keys for each new session. This has the effect of imposing an extra cryptography tax" on communications over and above the already expensive handshaking process required by secure protocols like SSL. Accompanying the introduction of PFS has been a move to take advantage of ECC (Elliptical Curve Cryptography). One of the primary benefits of ECC is that it can provide comparable security with shorter key lengths to RSA with longer key lengths. When you're generating ephemeral keys on a per-session or per-message basis, the shorter key length helps reduce the burden imposed by the additional cryptographic functions. Now, the problem is that cryptography is still compute intense and even leveraging ECC for PFS you're still going to incur performance penalties in setting up the session. Certainly custom cryptographic hardware acceleration would be a boon, but in cases where software-only solutions are desired, this is problematic. So the question is, how do you support enhanced security with PFS and ECC while still achieving blazing fast performance and extreme capacity? Obviously I'm about to tell you, so read on... Next-Generation Cryptography LineRate achieves what sounds like the impossible: really fast, really scalable secure communications in a software solution deployed on commodity hardware. By combining a highly optimized network stack with the ability to reach down into some of the lesser known capabilities in commoditized hardware, LineRate is able to achieve up to 25,000 new SSL sessions per second on the same commodity Intel CPU on which only 6,000-8,000 new SSL sessions per second were achieved using RSA-based cryptography. This remarkable feat is achievable through both focused engineering of the network stack and the use of a set of specialized instructions in the processor that are advantageous for the type of operations involved in ECC. These are not the same instructions as used in AES-NI, which is applicable to the easy part of SSL (bulk encryption) and aren't actually cryptography-specific instructions; they're just instructions that turn out to be really useful in speeding up the execution of certain computations associated with ECC. What this means is organizations can now take advantage of stronger security and longer (ostensibly also stronger) keys without incurring significant lags in establishing sessions. That's critical, as the longer it takes to establish a session, the more likely it is that the end-user will abandon the entire interaction. The appearance of not loading or that the site (or app) has "hung up" due to the time incurred by establishing a secure session can be devastating to the customer quality of experience. Quality of experience is rapidly outpacing other key performance indicators as a measure of success as businesses move toward an application-based economy in which engagement is key to driving revenue and customer satisfaction. A 2012 survey conducted by LSI Corporation highlighted not only the critical nature of performance (90% of respondents acknowledge this), but the disturbing reality that a majority of them (75%) do not feel they are achieving required performance. As we strengthen security to combat rising application and network attacks against protocols and applications themselves while simultaneously adopting emerging technologies and architectures designed to enable the next generation of data center networks, we must pay attention to the impact on application performance and capacity. Software-based solutions can provide the agility and service velocity demanded and necessary to enabling the app economy, but without careful consideration for the impact on performance a move toward such architectures can result in much more costly, complex networks. LineRate's attention to both performance and security offer organizations a flexible, software-defined and software-deployable solution that scales with simplicity.
