The PKI Guy drills down on PKI operations with Jeff Stapleton, author

Q&A with J.J. Stapleton, co-author of Security without Obscurity: A Guide to PKI Operations

TPG: What practical advice do you have for an organization considering deploying a PKI solution?

JS: There are various PKI architectures to consider. An internal private PKI deployed wholly within the
organization, a hosted private PKI deployed at a third-party service provider, or an external public PKI operated by a commercial third party. Each has pros and cons.

An internal private PKI requires human, equipment, and facility investments. Human resources include information technology (IT), information security (IS), physical security, internal audit, and legal support. Likely there will be a learning curve on all fronts. They will also need development, testing, quality assurance (QA), and production environments. Once deployed, the private PKI certificates will only be beneficial to users and applications running on the internal network for several reasons. The certificate authority (CA) certificates will not be available to external entities such as browsers, mobile devices, or applications unless the CA certificates are installed. Certificate status checking mechanisms, such as a certificate revocation list (CRL) or on-line certificate status protocol (OCSP) responders, will not be accessible unless deployed within the network demilitarized zone (DMZ). The private PKI will not be trusted by external entities unless it has undergone a professional assessment such as a WebTrust for CA audit.

A hosted private PKI might be much less work as the provider offers many of the resources, such as IT, IS, and physical security. However, the organization still needs to develop and maintain its certificate policy and certificate practice statement (CPS) so internal audit and legal resources are still needed. The hosting provider might offer the various environments. Thus, the initial investments
might be traded off by the hosting provider but there are ongoing fees and service level agreements (SLA) considerations. However, it is still a private PKI so it will only be beneficial to users and applications running on the internal network.

An external public PKI avoids many of the initial investments issues, but the lines of business (LOB) and legal need to accept the public PKI security controls and more importantly its warranties and liabilities. For example, the CPS relying party agreement (RPA) and the subject agreements might not address the LOB or legal concerns. Also, there will likely be a cost per certificate so depending on the size of the organization, the fees, SLA, and other operating costs might not scale. In this scenario, the private PKI problems for external entities are no longer an issue, but conversely the publicly available CRL and OCSP might not be accessible by internal entities unless the public CRL and OCPS can be reached via the network DMZ.

TPG: Why is a holistic approach to PKI needed?

JS: When PKI was in its infancy, we used to describe it as the intersection of technology, cryptography, and legal disciplines. This is still true today, but Clay Epstein and I noted in our book that the business needs also need to be considered. For example, there are differences between certificates used to secure a 15-minute web browsers session, versus certificates used for securing three-year emails, versus certificates used to sign 20-year mortgage documents.  The sensitivity of the data, the longevity of the information, and now privacy all need to be considered and addressed by the PKI in its design, operations, and management.

TPG: What security controls do you recommend for highly-secure PKIs?

JS: There are essential controls needed for any high-risk application, such as multifactor authentication for its administrators, clear separation of duties, and independent auditing outside the operational management structure. But for any PKI, the CA private keys used to sign the certificates must be protected using cryptographic hardware security modules (HSM) that are FIPS 140-2 certified at security level 3 or better level 4. Note that there are other equivalent certification programs out there. Another important control is that the messages between registration authority (RA) and the CA are signed, but this is rarely done. Regular audits are critical, as is having a proactive policy authority (PA) keeping the CPS and agreements current.

TPG: What type of background does an information security professional need to have in order to implement a PKI solution?

JS: PKI is applied cryptography. Having a foundational understanding of symmetric and asymmetric cryptography is essential, along with practical key management experience. But the practitioner also needs to have IT and general IS knowledge. Some auditing background is beneficial. And basic project management skills will help them coordinate the commonalities and differences between the business, legal, and operational viewpoints.

TPG: What are your thoughts on asymmetric cryptography?

JS: Asymmetric cryptography along with hashing gives us digital signatures, the cornerstone of PKI, to secure certificates and eventually the business information. However, it’s not a secret that quantum computers pose an inevitable risk to asymmetric cryptography. Researches tell us that it’s no longer theory, but an engineering problem. So, working backwards from when today’s asymmetric algorithms need to be replaced by post quantum cryptography (PQC), factor in the data retention lifecycle (e.g. days, months, years) and the historical cryptographic transitions we have seen in our past experience, the time for migration might have passed us already.

TPG: How do you see cryptography changing in the next 5-10 years?

JS: When I started, we encrypted personal identification numbers (PIN) at automated teller machines (ATM) and point-of-sale (POS) terminals. We used manual procedures to deploy symmetric keys. Today, we use asymmetric keys to transport symmetric keys, establish symmetric session keys, sign business data, and deploy certificates on web servers, mobile devices, and those same ATM and POS terminals. Tomorrow, we will be securing the Internet of Things (IoT) using PQC or maybe lightweight cryptography, ranging from individual microchips in tiny little devices to thousands of chips inside large machines including our cars.

TPG: What are the most important sections of the Certificate Policy and Certificate Practice Statement (RFC 3647) that many organizations struggle with or tend to ignore?

JS: Everyone is pretty good at the technical aspects, information security, physical security, and personnel security. Section 9. Business and Legal Matters seems to be the trickier bit. The warranties and liabilities often do not coincide with the business concerns. This is why getting the LOB and legal involved when developing or evaluating a CPS is so important. The CPS format (RFC 3647) has placeholders for the RPA and other agreements, but in practice these are often published as separate
documents. Santosh Chokhani and Warwick Ford once told me that they never expected the CPS to be such a pivotal document. When Randy Sabett, Chas Merrill, and Stephen Wu updated the format they did a great job, but they could not have envisioned such huge variety and specialization within so many diverse PKI over so many discrete industries. This is one reason why the Accredited Standards Committee X9 for the Financial Services Industry launched its PKI Study Group (and a TLS Study Group) to assess PKI for financial services.

TPG: What do you see as the top cyber threats?

JS: To be clear, cybersecurity and cryptography are not the same thing. We did a talk at the RSA 2018 Conference called Cyber Is Hot; Crypto Is Not. Sandra Lambert, CEO of Lambert & Associates, and I talked about how cybersecurity can help secure cryptography, which includes PKI, but at the same time how poor key management can undermine cybersecurity. Old algorithms, aging keys, weak access controls, bad processes, buggy software, and undocumented procedures can negate strong cybersecurity. If the gatekeeper is vulnerable then the gate is vulnerable.

TPG: What are the best ways for an enterprise to document its methodology?

JS: Write them down, review them on a regular basis, and update as needed. There are policy, standards, practices, and procedures. Policy and standards might be managed at the corporate level,
practices might be maintained at the division level, and procedures are handled by operations groups. However, depending on the size of the organization, all of these roles might be performed by a very small group. Undocumented processes are bad enough, but having documented ones that are not followed is worse.

TPG: With the rise of IoT, what new challenges or issues do see that didn’t exist when you wrote the book?

JS: To be honest, IoT has been on my radar for a while, but I didn’t know to call it that. Of course, I wasn’t thinking about wireless lightbulbs sending performance data or receiving firmware updates. Refrigerators and definitely vehicles were on my watch list along with a few other things we cannot really discuss. Suffice it to say that device certificates, code signing, and even trusted time stamps
have been recommendations for many years.

TPG: Can you give a funny example of a PKI that didn’t go as planned?

JS: Funny ha-ha or funny weird? Back in my MasterCard days, we designed something called Secure Electronic Transaction (SET). It was a joint venture with Visa. There was a SET root CA at the top tier, several intermediate CA at the middle tier for each credit card brand, then each brand CA had three issuing CA at the lowest tier. The brand level CA included MasterCard in USA, Nippon Shinpan in Japan, Dankört PBS in Denmark, Visa CA in USA, and Cyber-Comm CA in France. Then, as I mentioned each of the brand CA had issuing CA for the cardholder, the merchants, and Internet payment gateways. So, there were twenty one CA in all if I added right.

One of the many companies involved was Netscape, and one afternoon, Taher Elgamal drew his PKI protocol idea on the whiteboard, and said he was thinking about calling it Secure Socket Layer (SSL). So, I guess I was one of the few to see SSL version zero in the early days. Meanwhile, during the
development and testing of SET, I left MasterCard and eventually ended up at an auditing firm who ironically was awarded the contract to perform a security assessment of the five SET brand CA. We had just moved to Boston, in fact still unpacking, when I got a call, and the next day I was on a plane to Japan. But, after all that work, eventually SET was decommissioned, superseded by SSL and later
TLS.