Public Key Security
External
Internal
Overview
Asymmetric Cryptography
Asymmetric cryptography or public key cryptography is a cryptographic system that uses pairs of keys: public keys, which may be disseminated publicly and widely, and private keys that are known only to the owner, to provide authentication and encryption.
Authentication
The authentication function is provided by using the public key of the counterpart to verify that a message was indeed signed with the counterpart's private key. This mechanism works because the private key that signed the message cannot belong to anyone else than the counterpart whose public key was used for verification. This proof is considered sufficient to insure that the counterpart is who it is claiming to be.
Encryption
The encryption function is provided by using the public key of the recipient to encrypt the message. The message thus encrypted can only be decrypted by the corresponding private key, available only to the recipient. Nobody else can decrypt the message.
Public Key Infrastructure (PKI)
A public key infrastructure (PKI) is a set of roles, policies and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public key cryptography. The components of the architecture are aimed at binding public keys with respective identities of entities owning those public keys, such as people or organizations. The binding is established through a process of registration and issuance of certificates at and by a certificate authority (CA).
Certificate Authority (CA)
A certificate authority digitally sings public keys given by its users, whose identity and credentials were previously verified by the registration authority and generates signed digitally certificates. Because the CA signs the users' public keys with its own private key, the trust in the user public key relies on one's trust in the validity of the CA's key.
OpenSSL can be used to implement a simple CA.
Registration Authority (RA)
The registration authority (RA) is responsible for accepting requests for certificates and authenticating the entity making the request.
Key Pair
A key pair consists in two separate but matching cryptographic keys: a public key and a private key. The public and the private keys are generated at the same time. Key pairs can be generated in multiple ways, several examples are available below:
Public Key
A public key is widely disseminated, shared with any party and used to encrypt data. Data such encrypted can be only decrypted by matching private key. The public key can also be used to verify a signature - data encrypted with a specific private key can only be decrypted with the matching public key.
The public key can be always generated from the corresponding private key.
Private Key
The private key is kept secret, and it used to decrypt data that was encrypted by the matching public key. Content encrypted with a specific public key becomes opaque to everyone except the owner of the corresponding private key. The private key can be used to sign data - content such encrypted can be decrypted by the widely available - and presumably trusted - public key, proving that the signer of the content is indeed the owner of the private key.
The default RSA key size is 512-bit, which is too small to withstand brute-force attacks. It is a good idea to always configure the key size when generating it to at least 2,048 bits.
Private keys can be protected by password, but this is inconvenient during day-to-day operations: the operators of a web server might be asked for the password every time the web server is restarted. using protected keys in production does not actually increase the security much, because once activated, private keys are kept unprotected in memory and an attacker who can get to the server can get the keys with just a little more effort. If better key security is needed, a hardware solution is a better choice.
With OpenSSL, the private key contains the public key information as well, so a public key doesn't need to be generated separately. The length of an existing key can be displayed with openssl tools.
Encryption Algorithms
RSA
This is the most common choice for web servers, because DSA keys are limited to 1,024 bits.
DSA
Digital Signature Algorithm.
The DSA keys are limited to 1,024 bits on some browsers, so RSA is a better choice.
DSA key generation is a two step process:
ECDSA
Certificate Signing Request (CSR)
A CSR or certificate signing request is a block of encoded text that is given to a certificate authority (CA) when applying for an certificate. It is usually generated on the server where the certificate will be installed and contains information that will be included in the certificate such as the organization name, common name (domain name), locality, and country. It also contains the public key that will be included in the certificate. The matching private key is usually created at the same time that you create the CSR, making a key pair. A CSR is always signed with the private key corresponding to the public key it carries. A CSR is generally encoded using ASN.1 according to the PKCS #10 specification.
The CSR contains the following information:
- Common name: the fully qualified domain name (FQDN) of the server. This must match exactly the URL used on the browser, or the request will fail with name mismatch error. A wildcard name is acceptable.
- Organization: the legal name of the organization.
- Organizational unit
- City/Locality
- State/County/Region. State or region should not be abbreviated.
- Country. The two-letter ISO code for the country where the organization is located.
- E-mail address. Organization e-mail address.
- Public key: the public key that will go into the certificate.
CSRs are usually generated in PEM format.
CSR generation examples are available below:
Certificate
A certificate is a digitally signed statement vouching for the identity and the public key of an entity.
The certificate contains the identity of the server (its URL), the public key of the server and a digital signature that validates the certificate.
Certificates can be either self-signed or issued by a Certification Authority (CA).
Self-Signed Certificates uses its own private key to sign itself, and the signature is unverified - not connected to any chain of trust. This makes them inherently less secure.
An Authority-Signed Certificate is a certificate that is used to a party by the certification authority (Verisign, CAcert, RSA, etc.). The certification authority verifies the authenticity of the holder of the certificate.
Certificates are specified using the X.509 standard.
Enter keystore password: test123
Keystore type: jks
Keystore provider: SUN
Your keystore contains 3 entries
twiddle-2, Dec 9, 2009, keyEntry,
Certificate fingerprint (MD5): F0:EE:FD:F8:4C:C6:B7:9B:6F:C0:23:64:C1:25:F3:67
twiddle-1, Dec 9, 2009, keyEntry,
Certificate fingerprint (MD5): 8C:67:CB:CA:A7:A5:C0:BB:D8:F0:83:0E:59:27:56:02
omega, Dec 9, 2009, trustedCertEntry,
Certificate fingerprint (MD5): 2A:E2:78:C6:1D:BF:85:47:6C:05:E0:44:9B:74:D1:D5
Examples:
- OpenSSL Self-Signed Certificate Example
- OpenSSL Certificate Signed by a Local CA
- GoDaddy Certificate
Self-Signed Certificate
A self-signed certificate does not require a CA to sign it, it is signed with the private key corresponding to the public key in the certificate. For the associated procedure, see:
When securing a Tomcat server, it was sufficient to configure it with a keystore containing just an RSA key pair in it (generated with keytool -genkeypair). There was no need to actually produce and CSR, get a self-signed certificate and install in in the keystore. This makes logical sense: the keystore contains the private key that would be used to sign the public key, and also the public key so nothing else should be necessary.
Certificates Valid for Multiple Hostnames
In case of related web sites, it makes sense to use a single multidomain certificate. Even for a single domain, the certificate must support all possible paths that end users can take to reach it, as in "www.example.com" or "example.com". There are two mechanisms for supporting multiple host names in certificates. The first is to list all desired hostnames using an X.509 extension called Subject Alternative Name (SAN). When a certificate contains alternative names, all common names are ignored, so all desired hostnames must be included on the alternative names list. The second is to use wildcards. A combination of these approaches can also be used. Wildcards is usually sufficient.
More details available in "OpenSSL Cookbook", section "Creating Certificates Valid for Multiple Hostnames".
Certificate Operations
Trust Store
A repository of trusted root certificates is known as a trust store. Usually, each OS has a built-in truststore.
Mozilla is maintaining a robust trust store, in a proprietary format:
Third parties are converting this trust store into a PEM format, one of the sites where such a cacert.pem can be found is:
Certificate Generation and Installation Procedure
This is a high level procedure to generate, sign and install a server certificate. It contains the overall workflow and reference to specific operation pages, depending on the available tools and use case.
- Generate the private key. Private keys can be generated with OpenSSH and keytool.
- Create the certificate signing request (CSR). CSRs can be generate with OpenSSH and keytool.
- Send the certificate signing request to CA for signature. The CA will return a digitally signed certificate. OpenSSL can be used to generate a self-signed certificate, either from a CSR, or directly using the private key associated with the certificate.
- Install the certificate on the server.
- Optionally, for self-signed certificates, install the certificate on the client system.
- TODO: morph https://home.feodorov.com:9443/wiki/Wiki.jsp?page=SignedSSLCertificateInstallation into this document.
Standards and Formats
ASN.1
ASN.1 can be binary serialized as DER.
DER
Distinguished Encoding Rules (DER) is a binary serialization (encoding) of ASN.1 format. In the context of a PKI, DER is one of the formats used to encode keys and certificates. DER can be further Base64-encoded as PEM.
PEM
PEM or Privacy Enhanced Mail (RFC 1421 - RFC 1424) is a Base64 encoded DER format. In the context of a PKI, PEM is one of the formats used to encode keys, certificate signing requests and certificates. The PEM-encoded certificate content may be in X.509 or other formats. One of the characteristics of the format is that it contains very distinct headers and footers. The following header/footers are typical:
-----BEGIN CERTIFICATE REQUEST----- ... -----END CERTIFICATE REQUEST----- -----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY----- -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----
If a password was used to encrypt the private key, the header/footer are slightly different:
-----BEGIN ENCRYPTED PRIVATE KEY----- ... -----END ENCRYPTED PRIVATE KEY-----
OpenSSL generates private keys in PEM format by default.
Example of private key in PEM format:
-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQCgf3Pd91a3MX78QBU2Zn9dhXN12j4F+fqhvBTfBxDuoE89vngi
PmWFqtgjuQYwgoEiPwya0kZ4DWXVkgwIFQbXZXJE4QYQ6qOeZxSquvLUtawkCH+v
LM2fLFA/16zQAb0h9+bYruQSrX3ejTSAN/b60ufD8I0ACRtK5M4cZT9W5wIDAQAB
AoGBAJtWgAhHSbCIwUTXqTA7x+32KafZEMqsBX3gEbtClYq/sbIq1Q8foRbcIdGB
VJJC3UUODN8TwYyUOwmYDvkLkNAD/k3ADix5TLi7+RiQY+h+SsierZjP+X0SWtmH
T2FVU9wsBSC7KsEJs2umW9WpAxbiBqgSBHpckXjA1y2fBkChAkEA0rtiBQ6uS5Yq
CdLpTOHqKj4u72/slsQAIgF87r6etpKvOtxWT27nak92SvEp6SFVh9gUfgEgRkZC
T/hDOLz+CQJBAML5ldHWIH2MpKfVb80N3pjx3VQO4d/co/TozkhUFNhtWZxzF/4E
Eqpg6FpBOOP74fUAKac0htAL6LI3oR0f6W8CQQDOAil80DFL620FVY6FfoUw7sFr
iXs8mDeZBuNfcjIuQY/UdvpZhQ3uO+hkswZJxjCbMH44AFnQ2XaSPx1YJkohAkBv
wFQByGQo8cKyO6Bv/EIYkZBVDI6kG7eRuRn61M552fshs8oNmtID+7VRfc6YxZcW
MPiu0Glwt1KxSzc6FT9bAkANjm2XFKcaJgOimdhW/unKI5G8eLW2fvYImqDkwVM6
BcTTK1grKhbvddPkhOUS8dZdk2F+mcG85LeyWeK3hEGi
-----END RSA PRIVATE KEY-----
Public-Key Cryptography Standards (PKCS)
PKCS#8
PKCS#8 is one of the family of standards called Public-Key Cryptography Standards (PKCS), published by RSA Laboratories. The public keys generated by OpenSSL are by default stored in PKCS8 PEM format.
PKCS#12
PKCS#12 is one of the family of standards called Public-Key Cryptography Standards (PKCS), published by RSA Laboratories. It defines a file format commonly used to store X.509 private keys with accompanying public key certificates, protected with a password-based symmetric key. It's commonly seen with .p12 and .pfx extensions.
Private keys in PKCS#12 format can be generated with keytool by converting keys in native format:
PKCS#12 format keys can be converted to PEM with openssl:
X.509
X.509 is a ITU-T standard for a public key infrastructure (PKI). It specifies the format of certificates. For more details, see:
SSL/TLS
Transport Layer Security (TLS) is the successor of Secure Sockets Layer (SSL). They are both cryptographic protocols designed to provide communications security over a computer network. The client/server pair use a symmetric key to encrypt the communication. The symmetric key is unique and generated for each connection, as part of a protocol exchange that involves pair's public and private keys, using asymmetric cryptography. For more details, see:
To Process
- Example of RSA Encryption-Decryption with Keys from Different Key Stores http://localhost:9627/personal/Wiki.jsp?page=ExampleOfRSAEncryptionDecryptionWithKeysFromDifferentKeyStores
- Example of RSA Encryption-Decryption Same Key Pair http://localhost:9627/personal/Wiki.jsp?page=ExampleOfRSAEncryptionDecryptionSameKeyPair