Introduction
In Public-Key Infrastructure (PKI) schemes, the public component of asymmetric encryption keys are published as public certificates for anyone to use to encrypt messages for a target recipient. Messages encrypted using the public key may only then be decrypted and read by the target recipient who has access to the associated private key.
PKI is commonly used with Transport Layer Security (TLS), enabling the establishment of encrypted channels to ensure the confidentiality and integrity of communications between two points, as well as enabling an end-user to authenticate the identity of the server they are communicating with.
To enable functions fundamental to providing the advanced shielding service, RedShield must hold the private key and certificate for each protected website. As the disclosure of private keys may result in the compromise of all communications to these sites, RedShield makes significant efforts to ensure the keys are appropriately protected. These are outlined in this document.
RedShield Key Management
Key Submission
RedShield provides a secure upload facility for the sharing of sensitive data such as private keys, the RedShield Vault (https://vault.redshield.co).
To request an upload token for the Vault, submit a request to support@redshield.co with your full name and email address.
Key Transfers
RedShield makes significant efforts to ensure they are appropriately protected, including:
- All communications to the Vault are encrypted using TLS configured following best practice standards.
- All stored private keys are encrypted using industry standard public key encryption. The Vault uses public key encryption to encrypt data, with private keys for decryption only available on RedShield TLS termination systems.
- Keys are only decrypted on RedShield systems where operationally required, thus reducing exposure.
- All systems are installed in data centres which meet industry standards for physical security.
These controls ensure that your private keys are protected throughout all stages of communication and storage.
https://www.ssllabs.com/ssltest/analyze.html?d=vault.redshield.co&hideResults=on
Geographic / Sovereignty Restrictions
Customers may have restrictions on where sensitive information may be disclosed. For example, this may require that private keys used to decrypt personally identifiable information of New Zealanders are stored only in New Zealand.
To meet these requirements, RedShield can ensure that only New Zealand based systems are utilised in providing the service. Note that utilising NZ only POPs may significantly degrade the resilience of the service in the case of significant adverse network or environmental conditions in New Zealand.
Incident Response
In the event that disclosure of private keys is suspected or confirmed, RedShield will initiate incident response processes which ensure alerting of relevant customer personnel / contact points, root cause determination and reporting, and restoration of service.
Key Management
Guidance for Private Key and Certificate Creation
Web browsers increasingly include controls that will reject PKI certificates which do not meet a strict list of criteria. To avoid issues, when creating PKI certificates, ensure that:
- The certificate is sourced from a reliable Certification Authority (CA). Carry out due diligence to ensure that the CA has a good track record for reliability and security.
- The certificate is created using strong key sizes and certificate signature algorithms. Key size should be at least 2048 bits for RSA keys and at least 256 bits for ECDSA keys. Only SHA256 is to be used for hashing functions.
- The certificate includes all hostnames used on the site. If your site will be accessible on both the zone apex (example.com) as well as (www.example.com), ensure that both are specified in the certificate. The use of wildcard certificates should be avoided, as these may have to be shared across many systems, increasing the likelihood and impact of a compromise.
For more information on best practices for private key and certificate creation, refer to https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices.
REFERENCES
For more information on best practices for the creation and management of PKI certificates, refer to:
- https://www.ssllabs.com/projects/best-practices/
- https://www.owasp.org/index.php/Key_Management_Cheat_Sheet
Comments