Trust, as it pertains to most components within a Public Key Infrastruture (PKI) is earned. It’s established as the result of some sort of evaluation. An evaluation that often involves a revocation check or policy check.

In the case of the root CA however, trust is *not* earned. In the case of the root CA, trust is assigned. This assigned trust is quite often mandatory from the perspective of subscribers and relying parties.

‘Assurance’ in the realm of PKI, tends to be one of those topics that is almost guaranteed to send a PKI design meeting down a rabbit hole. And unfortunately, many customers prefer the blue pill, rather than committing to an effort commensurate with a rigorous examination of risk, impact and assurance in the certificate space.

Few companies have the luxury of a dedicated full time professional PKI staff. More typical are those companies that assign this duty as an adjunct to someone with a separate primary function, such as AD engineering. As such, I find that many PKI practitioners don’t have PKI proficiency as a primary skillset. It’s easy to understand how a “just make it work” mentality can eventually creep into a PKI operational processes. Too often, operational efficiency easily trumps perceived security risks.

The Internet of Things (IoT), from a security perspective, ultimately equates to an ever increasing need to more securely authenticate people, services, computers and devices across a wide spectrum of platforms. This means that Public Key Infrastructure (PKI) issued digital certificates are playing an ever more important role as a secure authentication mechanism within the enterprise and beyond.

In the wake of the Heartbleed bug, many are faced with the daunting (and expensive) prospect of replacing the SSL certificates on those vulnerable systems. This is due to the possibility that the private keys of exposed SSL certificates may or may not have been compromised. In the end, since there is no way to know for sure if your private keys have been compromised, many are opting to replace the SSL certificates of the affected system(s).

On April 7, 2014 a severe vulnerability called “Heartbleed” was announced. Heartbleed is a vulnerability within the OpenSSL 1.0.1 series software that is described in the NIST CVE-2014-0160 announcement. In short, this vulnerability allows hackers access to portions of a vulnerable system’s memory, leading to the potential exposure of passwords, sensitive data, and certificate private keys on affected systems. Heartbleed accomplishes this by exploiting a weakness in the “TLS Heartbeat Extension,” exposing server memory. Even worse, this heartbeat attack can be repeated without the awareness of the victim, and each iteration reveals another 64k snapshot of memory to the attacker. This very serious vulnerability exposes the most sensitive data of affected systems.

The good news: the vulnerability has a patch. However, the widespread adoption of the OpenSSL 1.0.1 series software, coupled with the two years that this vulnerability has existed, means that the risks attributable to Heartbleed are enormous. Current estimates predict that over 500,000 systems may be vulnerable. Specifically, the Heartbleed vulnerability affects those systems that use OpenSSL 1.0.1 (a-f). Unfortunately, since this software is so widely implemented, many popular OS platforms are affected and thus vulnerable. I would suggest visiting the CERT Web Site for a more list of affected platforms. It is worth mentioning that this is a developing story, and as such, the list of affected platforms is likely to change.