The Fundamentals of PKI
A basic public key infrastructure comprises several elements that include certain policies, software, and hardware and is intended to manage the creation and distribution of digital certificates and keys. Digital certificates, on the other hand, can be considered the core of a PKI because they are used to create a linkage between the public key and the subject of a given certificate. Other key elements are outlined further:
- The first element is termed a “certificate authority” (CA). It is a service provider that is used to maintain authorization procedures (regarding the end-users, computers, or any other entities).
- The second element is termed a “registration authority.” For the most part, it is also known as a subordinate certificate authority because it is utilized to grant root access to specific users (Pfleeger, Pfleeger, & Margulies, 2015).
- The third element is a database that is used to store certificates and information regarding revocations, requests, and other activities.
- The fourth element is a certificate store that is used to keep the information regarding private keys or any of the certificates that were issued earlier.
After the identities of the end-users are verified by the CA, several digital certificates are issued. Then, a self-signed CA is utilized to disclose a public key to the parties that have access to it and enables a private key that safeguards the disclosed data. Another notion that is worth mentioning is a “chain of trust.” It can be explained by the root CAs that are embedded, for instance, in Web browsers and are enabled by default. The information regarding algorithms is also contained in these digital certificates.
PKI and the Company’s Software
One of how a PKI could help during the process of signing the company’s software is a solution that is solely based on the complexity of environments that are in control of testing and development environments. Therefore, the authenticity of the software can be tested using deploying a test certificate server that will deploy a test root certificate (Sinn, 2015). Microsoft’s Active Directory CA Services can be used to perform this task, but the option of Group Policy should be turned on so that certificates could be easily revoked and managed. Other tools can be used (such as OpenCA or EJBCA) but there is also a variety of way to deploy the CA testing procedure:
- First, the certificates should be issued to all CA testers and developers that are involved (Wu & Irwin, 2016).
- Second, certain requests to the server regarding the enrollment of certificates should be made by the client. The administrator should perform those requests either manually or using an ACL (Sinn, 2015).
- Third, the certificate requests may be made by certain power users (such as team leaders) to make it easier for the end-user.
One of the most important steps, in this case, is the automation of the signing process. Moreover, the developers are required to include the latter in the development environment. By doing this, the team will be able to evade issues and certify that the end product will be of high quality. This would highly benefit the users of complex environments that are usually forced to come up with several sets of signing requirements (signature packaging configurations and other conventional applications).
The Comparison of Public/ In-House CAs and Recommendations
Several advantages are characteristic of the in-house CA. First of all, this type of CA allows you to manage the available key and certificates in a simple and easily understandable way (Conklin, White, Williams, Davis, & Cothren, 2016). The key reason behind it is the decision to get rid of external entities and the absence of any dependencies that would interfere with the certificates mentioned above. Second, the CA can be used in pairs with Microsoft’s Active Directory.
This fact also positively influences the process of managing the CA. The disadvantages of the in-house CAs include, in the first place, the complexity of the implementation of this type of CA (Conklin et al., 2016). It is also safe to say that the organization, in this case, is responsible for the development and implementation of the PKI. The third disadvantage revolves around the fact that external parties will not trust an in-house CA.
The first advantage that relates to the public CAs is that the latter is ultimately in control of the organizational PKI. Moreover, the majority of external parties approve the certificates that are signed using trusted public CAs (such as SecureNet, VeriSign, or Comodo) (Wu & Irwin, 2016). One of the core disadvantages, at the same time, is that the linkage between the organizational infrastructure and the public CA becomes too restricted. Additionally, the use of public CAs generates more pay-per-certificate expenditures. In perspective, this means that there will be potential issues with the management of certificates and inflexibility of CA configuration (Pfleeger et al., 2015).
It is recommended to use the in-house CAs because there is no need to spend money on the pay-per-certificate services. Also, it should be noted that they are easy to configure and tend to be much cheaper than their public counterparts. They also positively affect the PKI and simplify the process of issuing new certificates.
References
Conklin, A., White, G. B., Williams, D., Davis, R., & Cothren, C. (2016). Principles of computer security (4th ed.). New York, NY: McGraw Hill.
Pfleeger, C. P., Pfleeger, S., & Margulies, J. (2015). Security in computing. Upper Saddle River, NJ: Prentice Hall.
Sinn, R. (2015). Software security technologies. Boston, MA: Thomson.
Wu, C. J., & Irwin, J. D. (2016). Introduction to computer networks and cybersecurity. Boca Raton, FL: CRC.