In order to determine the level of security it is important to step back and understand what a Public Key Infrastructure and the certificates associated with the Public Key Infrastructure can be used for.
Certificates can be used for identification, encryption, non-repudiation, and in some cases authentication. In your organization you probably have some standard on how a user receives a user account. Since certificates can be used for identification the same standard should be used when issuing certificates, if they are going to be used for that purpose.
If using the keys from the certificate for encryption, it would depend on what data is being decrypted. In other words the level of security is going to be determined by the level of risk. This determination should include any corporate security policies for PKI and certificates. When creating your PKI security policy, you should also consider any industry or government regulations.
The flexibility and scalability of your solution should be taken into consideration. If you have a high level of confidence that you will not need to change or adapt your PKI solution you can have a fairly simple design.
However, if you need a solution that will need to support a variety of technologies, different levels of security, and a global presence, then your solution can get much more complicated. When designing your PKI solution you will have to determine the hierarchy that you will use. There are generally three types of hierarchies, and they are denoted by the number of tiers.
A single tier Hierarchy consists of one CA. Any applications, users, or computers that trust the Root CA trust any certificates issued by the CA hierarchy. For security reasons, these two roles are normally separated. When using a single tier hierarchy they are combined. This may be sufficient for simple implementations where ease of manageability and lower cost outweigh the need for greater levels of security or flexibility.
In some ways it is a compromise between the One and Three Tier hierarchies. But more importantly the Root CA is offline, and so the private key of the Root CA is better protected from compromise.
It also increases scalability and flexibility. Cost is increased marginally. I say marginally, because all you need is a hard drive and Windows OS license to implement an Offline Root. Install the hard drive, install your OS, build your PKI hierarchy, and then remove the hard drive and store it in a safe.
The hard drive can be attached to existing hardware when CRLs need to be re-signed. A virtual machine could be used as the Root CA, although you would still want to store it on a separate hard drive that can be stored in a safe. The placement of this CA can be for a couple different reasons.
In other words the Policy CA is configured to issue certificates to the Issuing CA that is restricted in what type of certificates it issues. The Policy CA can also just be used as an administrative boundary. In other words, you only issue certain certificates from subordinates of the Policy CA, and perform a certain level of verification before issuing certificates, but the policy is only enforced from an administrative not technical perspective.
Following the paradigm, security increases with the addition of a Tier, and flexibility and scalability increase due to the increased design options. On the other hand, manageability increases as there are a larger number of CAs in the hierarchy to manage. And, of course, cost goes up.
One of the key aspects of designing a PKI solution is to make sure the proper controls are in place. Clients and application verify the signature so that they can be assured that a certificate was issued by a particular CA. Although this method does provide protection it does not prevent a user that is a member of the Administrators group on the CA from accessing the private key.
This can be a cause for concern, because you may have administrators whose job is just to patch the system, and yet they have access to the private key which violates the concept of least privilege. There are generally two methods for protecting the private key of a CA. The first method is to keep the CA offline and the hard drive stored in a safe. By controlling the conditions the hard drive can be used, the opportunities for key compromise are reduced. The second method is to use a hardware device to protect the private key.
For example, a smartcard can be used to store the private key of the CA. This is not the best solution since the smart card must remain in the reader attached to the CA in order to be used. Also, a smart card may not be as resilient, or provide the level of security that is required. It is however a low cost solution. Aside from private key protection you will most likely want to have some control as to the level of administrative access to a CA.
In some cases you may have administrators that are responsible for performing every function on the CA. But in larger or higher security environments you will want to have some granular control over what access different role holders have.
Below is a list of common roles on a CA:. In addition to these roles that have direct interaction with the CA, you also will have ancillary roles that support the CA. These include:. Certificates issued by CAs are used in many cases for very sensitive operations such as establishment of identity, authentication and encryption. As such, it is important to not only protect the private key but to protect physical access.
This will depend on the resources you have available, but typically in larger organizations the CAs are stored in a locked cage in a data center. Only individuals that need physical access to the CA to perform their duties should be given access. Generally the security requirements, such as those mentioned above, are dictated by a corporate security policy. A security policy usually takes into consideration regulatory and industry requirements as well as unique requirements for the individual company.
The policy may also specify technical aspects of the PKI such as the encryption algorithms that must be used as well as operation of the Certificate Authorities. In addition to security policies there may be CA-specific policies that need to be developed before implementing the PKI.
The Certificate Policy explains what methods are used to establish the identity of a subject before issuing a certificate. Many companies, especially third parties companies that issue certificates, have their Certificate Policies and Certification Practice Statements available publicly.
It may be helpful to view one of these public documents when writing your own policy documents. In addition to the topics discussed it is important to apply any relevant security patches to your online CAs and to install them in a timely manner. In addition to patches, you should have an anti-malware solution installed on your CA.
So far we have covered reasons to deploy a Public Key Infrastructure. We also have covered the various costs involved in a PKI infrastructure, as well as the impact of various design considerations. Now we will dive a little deeper into specific configuration decisions and technical aspects of the Certificate Authorities. Digital certificates have a lifetime, a start date and an end date for which they are considered valid. For end-entity certificates there are a number of factors taken into account:.
The certificate issued will be configured with the validity period that is the shortest of these items. The length of a key definitely affects security of information protected with that key.
Thus, you will need to determine the key lengths you will use with each key pair. First you will need to determine the key lengths that will be used for each of the CA key pairs. Additionally, you will need to determine the key lengths for any certificates issued by the issuing CA. The key lengths for the CA certificates are determined by the key size requested when the CA is installed and when the key pair is renewed.
The key length at installation is set during the CA Setup process. The key length for renewal is determined by a value set in the CAPolicy. For certificates issued by the issuing CA the maximum key size is limited by the CSP that is being used.
The specific key size that is required can be specified in the certificate request or in the Certificate Template if using an Enterprise CA. As a general guideline, the longer the lifetime of the certificate the longer the key length should be. For applications that will be using certificates you will need to determine the maximum key length they support.
Some applications have limitation on the key size not only in the actual certificate it is using, but also for any certificates in the CA hierarchy. From a security standpoint it is recommend that bit key is used for Certification Authorities key pair. However, if you wanted to insure maximum compatibility with network devices and applications a bit key would be the better choice. When a client or application is validating a certificate it needs to not only validate the certificate that is being used but also the entire chain of the certificate.
In other words, the application or client needs a certificate from each CA in the chain beginning with the issuing CA and ending with the Root CA. If the application or client does not have access to the certificates in the chain locally the application or client needs a place from which to obtain the certificates.
The AIA location is the repository where the CA certificate is stored so that it can be downloaded by clients or applications validating a certificate. Before implementing your PKI it is important to think about what types of clients will be validating the certificates and where they reside.
If you are using Windows clients that are internal to your network and are domain members then LDAP locations in Active Directory are a good place for clients to access the AIA repository. If you have non-Windows clients or Windows clients that are not domain members that are internal then an internally hosted web site would be the ideal location for the AIA repository. If the security solutions supported by the PKI do not require external parties to trust the issued certificates, and will not in the future, then you may opt for a self-managed PKI that uses an internal root CA as the trust anchor for the PKI.
Using an internal root CA allows you to maintain direct control over its security policies and to align its Certificate Policy CP with the overall security policy. Therefore, you will use internal CAs for issuing certificates to end users, to computers, and to services.
These internal CAs can be expanded to include additional functionality, such as support for new certificate types, at a lower cost than buying external certificates. In a hierarchical PKI a typical deployment , there are generally three types of hierarchies — one tier, two-tier, and three-tier. Any applications, users, or computers that trust the root CA also trust any certificates issued by the CA hierarchy.
The issuing CA is a CA that issues certificates to end entities. This one-tier hierarchy is not recommended for any production scenario because with this hierarchy, a compromise of this single CA equates to a compromise of the entire PKI.
For security reasons, root and issuing CAs are normally separated because it is generally very difficult to quickly distribute a new root CA certificate to replace a compromised CA. This is especially true when the environment includes computers not joined to management domain or devices where a special process is required to provision the root CA certificate. Because of this, a one-tier hierarchy may be sufficient for only simple implementations where ease of manageability and lower cost outweigh the need for greater levels of security or flexibility.
A common finding in PKI assessments is that some organizations install a single CA in order to support a major project that may have required it. Over time, this single CA begins to get a lot of use as it is leveraged more and more for purposes other than those originally conceived. Suddenly, there is a need for a proper PKI and administrators face some uneasy questions:.
So there are multiple security risks in using a one-tier hierarchy — your only CA is online and more susceptible to compromise, and you cannot revoke this CA if it was compromised. This hierarchy is also more difficult to expand to support other scenarios. Three-Tier Hierarchy — In a three-tier hierarchy, there is a root CA tier offline , an issuing CAs tier usually online , and an intermediate tier placed between them.
The placement of this intermediate CA can be for several different reasons. The first reason would be to use the second tier CA as a policy CA. For example, one policy CA will issue certificates that requires that a user has to appear in person and another CA will issue certificates to any authenticated corporate users. In other words, the policy CA is configured to issue certificates to the Issuing CA that is restricted in the type of certificates it issues.
The policy CA can also just be used as an administrative boundary. That is, you only issue certain certificates from subordinates of the policy CA, and perform a certain level of verification before issuing certificates, but the policy is only enforced from an administrative and not technical perspective.
Another reason to have the second tier added is that if you need to revoke a number of CAs due to a key compromise, you can perform it at the second tier level, leaving other branches available. It should be noted that second tier CAs in this hierarchy should, like the root, be kept offline. Following the paradigm, security increases with the addition of a tier, and flexibility and scalability increase due to the increased design options.
0コメント