Information Security Management Handbook, Sixth Edition (2012)
DOMAIN 3: INFORMATION SECURITY AND RISK MANAGEMENT
Chapter 8. Risk Management in Public Key Certificate Applications
As public key certificates technology became an enabler for many security controls, it became more important to understand all types of risk associated with the use of this technology and its processes and components. This understanding is necessary to address and mitigate the risk and also to make intelligent design decisions that would afford a desirable performance and availability without jeopardizing confidentiality, integrity, and other security requirements. As new technology trends, like cloud computing and service-oriented architecture, are maturing, the reliance on public key-based security controls, like digital signature and encryption, is increasing, as is the risk of misuse or compromise of the certificates. Several recent researches and publications (KMNSK, STRV) point at a few very specific vulnerabilities that can be exploited in the certificate applications.
This chapter is an attempt to analyze the risk surrounding the certificate applications in a little broader scope. In this chapter, there are two logical areas. One is dedicated to the risk analysis and threat modeling for public key infrastructure (PKI) services, their internal processes, and certificate life-cycle management (CLM). The second area relates to the risk analysis and threat modeling for some certificate-based applications and security controls. We will see in the concluding sections of the chapter how the security weakness of a PKI and the certificate services (CS) may negatively affect the security controls of the applications that are consuming the certificates provided by those services.
The scope of this chapter includes the risk analysis from a technology and processes point of view. It does not follow a thorough quantitative or qualitative risk assessment and risk management approach prescribed in the published guides, which would have to take into consideration the assets values and business impact. However, we do follow the “vulnerability-threat” methodology. This risk analysis may be useful as part of a full risk assessment and a risk management program, where a value of the potential loss or damage to the specific assets is factored in. This limited risk analysis may also help focus limited resources on the most critical areas of the public key certificates applications implementation.
We will perceive any vulnerability, as defined in the NIST SP800-30 publication (NIST80030), as a “… flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system’s security policy. …” Our risk analysis will include the analysis of vulnerabilities associated with the public key CS and the certificate applications processes, as well as the underlying technologies and implementation flaws, which could be exploited by potential threat sources.
Overview of Certificate Service Processes and the Relying Applications
Before analyzing the risk, let us try to identify the typical processes in the CS, the certificate-based applications, and the interaction between each other. These processes will be described very briefly just to lay a foundation for the following risk analysis. We will assume that the key components of a PKI and a CS have already been deployed, they have undergone the required acceptance processes like certification and accreditation (C&A), and are operated in accordance with their certificate practice statements (CPSs). Thus, the focus is on analyzing the risk associated with the consumption of these CS by different categories of applications, including certificate enrollment and PKI registration, the certificate life cycle, and the processes of certificate utilization.
PKI Registration, Certificate Enrollment, and Certificate Life-cycle Management
The processes, subprocesses, and phases of PKI registration, certificate enrollment, and certificates life cycle may be identified as follows:
Subscriber’s registration with PKI: This process may vary, depending on the class of the certificates, the boundaries of the user base, and the assurance level that these certificates are expected to support. For low-assurance certificates, the process may include just very basic validation of the subscriber’s name for its uniqueness in its domain. For certificates of higher-level assurance, the process may include additional proofs of identities. Upon successful validation of the subscriber’s identity, the subscriber’s directory entry may be assigned certificate attributes and an entry for this subscriber in the PKI database can be created.
Process of generating a public/private key pair: In many cases, this process takes place on the subscriber’s platform to ensure that a subscriber’s private key does not leave this platform, to support a higher assurance and nonrepudiation. This process may be implemented as an integral part of the certificate enrollment process or as a stand-alone utility (openssl, certutil, etc.). It may use the underlying libraries (e.g., Java class KeyPairGenerator) and random number generators (RNGs) from different sources. In those cases when future utilization does not imply nonrepudiation or requires key escrow, the key pair may be generated on the PKI CA site. This especially applies to the embedded PKI CAs, which support the certificate needs of the infrastructure components. For example, the key pair generating facility may reside on the management center of the firewall or the applications gateway and the keys would be distributed to the managed appliances in a secure fashion.
Process of generating a certificate signing request (CSR): This process chiefly includes binding the generated public key with the subscriber’s name and the certificate attributes. Similar to the key pair generation, this process may also be implemented as an integral part of the certificate enrollment process or as a stand-alone utility. The most important point here is to make the subscriber provide a proof of possession of the counterpart private key. For the signing of dual-purpose certificates, this proof is simply provided by self-signing, or by the subscriber’s digital signature, which can be verified by the registration authority (RA) or the CA.
Submitting a certificate request to the CA: The CSR can be submitted to the RA/CA via the network (e.g., HTTP or SMTP) or out of band. The implementation of messaging between the subscribers, the RA, and the CA depends on the vendor and the product. Although the CSR message does not contain a subscriber’s private key, its integrity and authenticity are critical. In cases when subscribers’ private keys (usually, it is a case for an encryption certificate) must be stored in the CA database, escrowed, or archived, the keys are transmitted in the encrypted message. A full description of all the messages between the subscribers and the RA and between the RA and the CA can be found in the IETF publication RFC 4210 (RFC 4210).
Certificate issuance and publication
– Messages between the subscribers, the RA, and the CA usually include a body in ASN.1 form, which is parsed and analyzed by the receiving side. It includes parsing and verifying the subscriber’s name, the public key, and the requested certificate’s attributes and message authentication code.
– When the requested X.509 certificate is generated according to its template, the issuing CA information such as the certificate revocation list (CRL) distribution point, the authority key identifier, and the digest are added. Finally, the certificate is signed by the CA.
– The certificate is added to the subscriber’s data entry in the PKI database and is published in the directory as a subscriber’s object certificate attribute.
Certificate revocation and validity status support: This process, in response to business events, publishes the certificate revocation status in the CRL. The status is also made available to an online certificate status protocol (OCSP) server, which responds to the relying parties’ real-time client requests. The frequency and availability of up-to-date certificate status information depend on policies and implementation.
Certificate renewal: This process may be initiated by a subscriber or automatically by the PKI when a certificate approaches the end of its validity. This process may allow reusing the old certificate’s keys or may require regenerating the key pair. In the latter case, the renewal is essentially a reissuing of a new certificate that should replace the old one.
Public Key Applications and Certificates Utilization
The relying parties and subscribers may implement a number of standard and application-specific protocols that utilize public key certificates and are very specific about certificate requirements, their attributes, extensions, life cycle, and utilization. The following are some of the protocols and applications that support specific security controls, which help the business applications meet their security requirements and objectives.
Secure application tunnels that implement transport layer security (TLS)/Secure Sockets Layer (SSL) for HTTP, lightweight directory access protocol (LDAP), File Transfer Protocol (FTP), and SSL virtual private network (VPN) applications. The certificates enable client and server authentication and negotiation of the symmetric session (ephemeral) key for data in transit encryption (tunneling).
Secure messaging (e.g., Secure/Multipurpose Internet Mail Extensions [S/MIME] and Simple Object Access Protocol [SOAP]), which provides message signing and encryption for e-mail applications, such as the Exchange/Outlook or SOAP messaging, over HTTP applications, and others. Senders encrypt their messages (or part of the messages) with symmetric keys and use the recipients’ certificates to encrypt that symmetric key. Therefore, only the recipients in possession of the certificates’ counterpart private keys will be able to decrypt the message. The sender also uses his private key for message signing. Therefore, a recipient can verify the sender’s digital signature with the sender’s public certificate.
Document and code signing applications would utilize a certificate and counterpart private key to generate a digital signature for data digest in a way similar way to what was described above for secure message signing.
File and folder encryption: After encrypting a file or folder with a generated symmetric file encryption key (FEK), a user encrypts the FEK with his (and optionally with other selected users’) and the data recovery agent’s (DRA) public key. The user and optionally other designated users (whose certificates have been used for encryption), as well as the DRA, use their private keys to decrypt the encrypted file.
Local and remote access control with strong authentication: Access control with certificates may be implemented as a separate application security control or as part of a suite. Both strong authentication and permission control are part of the access control, which are supported by certificates.
The implementers may use standard or individual custom processes for keys and certificates management, utilization, validation, etc. However, most likely, the processes will include some or all of the following:
Obtaining another party’s public key certificate: A relying party may receive another party’s certificate in several ways. For data encryption or encrypted communication purposes, the encryption certificate can be obtained from a receiver’s entry in an LDAP directory, from a receiver’s e-mail, or from other sources. For digitally signed messages, a sender usually attaches his certificate to the signed message. Peers of TLS/SSL applications would exchange the certificates in the TLS handshake protocol exchange (RFC 2246). The trusted CA’s certificates may be preinstalled on the clients’ software or distributed via trusted sources. For example, all browsers have VeriSign and other major commercial CA’s certificates preinstalled to support SSL/TLS applications, which have VeriSign certificates installed on their servers. Internal PKI CA’s certificates may be added to the organization’s standard build or distributed via software management processes.
Certificate validation: This process involves several steps, including verification of the CA signature, validity dates, attributes and extensions, and the subject name. The relying party application may also be forced to validate the counterpart certificates’ revocation status by checking the certificates in question against their CRL distribution points or by challenging the OCSP server(s).
Parsing and mapping a certificate’s contents: A relying party would parse a certificate when it needs to validate it (as described above) and also extract particular attributes needed for mapping for its application. The relying party’s application is using its ASN.1 parser and an X.509 template complying with the RFC 3647 standard (RFC 3647) with the expectation that the parsed certificate was generated in compliance with the mentioned standard.
Encryption and decryption: A sender encrypts data and messages with the recipients’ encryption public keys (in most cases, distributed as encryption certificates) and then the recipients decrypt that data with the counterpart private keys. As mentioned earlier, in many applications the asymmetrically encrypted data is a symmetric session key or a bulk data encryption key, and the recipient’s certificate can be obtained from different sources, such as the LDAP server or the recipient’s e-mail.
Signing and verifying the signature: Producing a signature (RFC 3126) may also include the process of attaching the signer’s certificate chain, so that the relying party would easily verify the signature.
Vulnerability in each of the mentioned processes and in their underlying technologies may be intentionally or unintentionally exploited. There is always some threat of internal and external origin, application flaw exploits, as well as human errors. For example, if a malicious user B can register as a subscriber A, then B can forge and submit a CSR on behalf of user A. Consequently, a third party, C, will be deceived when exchanging transactions with B instead of the legitimate user A. The scenarios when this type of situation leads to wrongly issued or wrongly validated certificates, as well as other incidents, will be analyzed in the following sections dedicated to risk analysis.
Risk Analysis for CS and Certificate Applications
Even when an application itself is generating a private/public key pair and issuing a self-signed certificate for its own use locally or sends it to other parties, that application is often using its local rudimentary PKI. More advanced embedded PKI, dedicated to support one or a family of products of the same vendor, may use certificate- and key-dedicated repositories and management mechanisms. The larger applications may leverage external commercial or in-house leveraged PKI to obtain, utilize, and support their public key certificates as an important part of their security controls. The processes of certificate enrollment and life-cycle management with their subprocesses and technologies have their own vulnerabilities that may be exposed. The PKI with its assets and resources may be a threat target, so performing an overall PKI threat modeling and risk analysis, at least on a limited scale, should be in order. All PKI interfaces that are available for legitimate subscribers and relying parties, as well as communication channels, represent the entry points that can allow the threats to exploit the PKI vulnerabilities. The scope of our analysis does not include vulnerabilities related to physical controls. Figure 8.1 presents a consolidated data flow diagram.
The suggested risk analysis will focus on collaboration between the CS, the subscribers, and the relying parties, as well as the ability of the serviced certificates to meet the security control requirements of the consuming applications. In the following two subsections, we will cover the certificate-based applications risk analysis and the CS risk analysis (including certificate enrollment and certificate life cycle).
CS Risk Analysis
For the sake of clarity, in this section, the scope of the CS and the related threats will be limited to certificate enrollment and CLM, which include certificate renewal, recovery, and revocation with status publication. The threats and their actions and exploited vulnerabilities are presented inTable 8.1. Diagrams of some of the threats associated with external actors are presented in Figure 8.2.
Figure 8.1 Certificate services, subscribers, and relying parties.
Table 8.1 Certificate Services Threats and Vulnerabilities
Figure 8.2 PKI registration threat modeling.
Certificate Applications Risk Analysis
The most common public key certificate applications have been described in the section Public Key Applications and Certificates Utilization. Any vulnerability in certificate enrollment or in the processes supporting the certificates’ life cycle may potentially translate into vulnerability of the relying applications and controls that utilize those certificates. Consequently, a particular threat source may successfully exercise a particular vulnerability of the public key certificate-based security control, which would result in an application security breach.
These threats and their actions and exploited vulnerabilities are presented in Table 8.2. The diagrams of some of the TLS applications threats associated with external actors are presented in Figure 8.3.
The certificate applications and security controls reviewed above, as well as other applications in general, have their own vulnerabilities that can be exploited. Risk, associated with those vulnerabilities, can be analyzed by traditional methods, such as static code analysis, scanning, and penetration testing.
However, we have to take into consideration and assess and mitigate the risk specifically related to certificate use and all supporting processes. Although PKI may be outside the application boundary, any weakness or flaw in it or its processes may affect both the subscribers and the relying parties as consumers of the CS.
Many vulnerabilities, which have been identified in the certificate-based applications in Table 8.2, are tightly related to the vulnerabilities in the PKI and the CS, which provide for those applications.
How the Applications Inherit the Risk
As we can see, the certificate-based applications and the security controls largely inherit the risk from the technologies and processes of certificate enrollment and life-cycle management implemented in the CS. There are several avenues for this undesirable inheritance.
Table 8.2 Certificate Applications Threats and Vulnerabilities
Figure 8.3 TLS applications threat modeling.
The latest achievements in cryptographic research and increased inexpensive computing power make the breaking of digital signatures easier. It allows the perpetrators to produce the certificates rooted to the publicly trusted CAs and to install them on rogue impersonating devices. The relying parties may be easily deceived unless they implement a very thorough certificate chain validation process.
New techniques implemented in the advanced persistent threats (APTs) against government, commercial, and private (internal) certificate authorities (PKI CA), are capable of circumventing the PKI RA subscribers’ authentication, certificate enrollment, and certificate life-cycle processes. Thus, the relying parties will trust the certificates inadvertently issued to fraudulent subscribers.
A poorly implemented process of certificate enrollment or life-cycle management may allow an attacker to obtain a private key associated with a trusted certificate, thereby allowing the attacker to impersonate a trusted party. It is likely to happen in private or integrated internal PKIs.
Many attacks on certificate-enabled applications and controls may be successful only in concert with successful attacks on and compromise of DNS servers. An attacker would replace a DNS entry on the server with a compromised certificate; therefore, a deceived relying party client will be pointed to the impersonating server with a fabricated certificate. Because that forged certificate’s chain is routed to the trusted CA certificate, the trusted connection will be established.
To minimize the impact of the inherited risks, many mitigation measures can be used, on both the subscribers’ and the relying parties’ sides.
The selection of the certificate providers and certificate requirements should be based on the application security requirements. An application security risk assessment should include the risk associated with the certificate-based security controls of that application. Only a CA that can provide an adequate life-cycle management of the certificate chain complying with the latest NIST cryptographic recommendations should be used. All new vulnerabilities in the embedded certificate solutions (e.g., open source libraries like OpenSSL) or in the external providers’ solutions (e.g., weakness of MD5 signature used in some publicly trusted root certificates) should be assessed and addressed.
Consumers of the CS (both subscribers and relying parties) need to familiarize themselves with certificate policies. Unawareness of certificate processes and the trustworthiness of the issuing PKI may degrade rather than upgrade the application security level.
The methods of certificate validation supported by the certificate’s providers, e.g., validation of the certificate revocation status (over HTTP/LDAP CRL access or OCSP) and extended validation (EV), should be used, even if supporting these features is adding some cost.
Consumers of the CS should make provisions for cases of certificate compromise as part of their incident and emergency response planning. For example, the vendors of Internet browser software may implement short- and medium-term response plans. They would include a simple notification of the users about a mistaken issuance of fraudulent certificates by the trusted CA and add those certificates to the untrusted certificates’ list (COMODOMOZ).
Public key certificate technology, as any other, has never been an absolutely bulletproofed enabler for security controls. Other traditionally very secure technologies, like a one-time password (OTP), can also be the targets for successful attacks (RSACOMP). For example, a compromised OTP seed file may drastically weaken an expensive Two Factor authentication control. The security breaches on certificate-enabled applications and controls are the results of implementation and operations flaws, so some prophecies about the upcoming demise of the PKI may be a little premature.
As with all other technologies, only the right processes and the timely implementation of advanced cryptography may keep the certificate-based security controls at an adequate level. The concentration on these problems is represented in the series of NIST and other publications. Some publications are focused on the certificate and key management and selection of cryptographic algorithms and key lengths for the new systems and upgrades (NIST800-57-1), and would be helpful for PKI implementations. Other publications (NIST800-57-3) are more specific and recommend application-specific keys and certificates guidance. These recommendations assume a realistic prediction of the cryptographic strength required to withstand the attacks today and in the predictable future.
Nystrom, M. and Kaliski, B. (RFC 2986) PKCS10: Certification request syntax specification version 1.7. IETF 2000. http://tools.ietf.org/html/rfc2986.
Higgins, K. J. (KMNSK) Black hat: PKI hack demonstrates flaws in digital certificate technology. Researcher Dan Kaminsky illuminates flaws in X.509 authentication. Darkreading 2009. http://www.darkreading.com/security/vulnerabilities/218900008/index.html.
(NIST80030) NIST Special Publication 800-30. Risk Management Guide for Information Technology Systems. July 2002.
Kaminsky, D., Sassaman, L., and Patterson, M. (LayerCake) PKI Layer cake: New collision attacks against the global X.509 CA infrastructure. http://www.ioactive.com/pdfs/PKILayerCake.pdf.
Adams, C., Farrell, S., Kause, T., and Mononen, T. (RFC 4210) Internet X.509 public key infrastructure certificate management protocol (CMP). PKIX-CMP http://tools.ietf.org/html/rfc4210.
Dierks, T. and Allen, C. (RFC 2246) The TLS protocol version 1.0. http://tools.ietf.org/html/rfc2246.
Chokhani, S., Ford, W., Sabett, R., Merrill, C., and Wu, S. (RFC 3647) Internet X.509 public key infrastructure certificate policy and certification practices framework. http://tools.ietf.org/html/rfc3647.
Pinkas, D., Ross, J., and Pope, N. (RFC 3126) Electronic signature formats for long term electronic signatures. http://tools.ietf.org/html/rfc3126.
(COMODO) Comodo report of incident on 15-MAR-2011. http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html.
Gabrilovich, E. and Gontmakher, A. (Homograph attack) The homograph attack. Communications of the ACM 45(2): 128, 2002. http://www.cs.technion.ac.il/~gabr/papers/homograph_full.pdf.
Samson, T. (RSACOMP) EMC: RSA SecurID info swiped via sophisticated hack attack. InfoWorld, March 2011. http://www.infoworld.com/d/security/emc-rsa-securid-info-swiped-sophisticated-hack-attack-917.
Keizer, G. (COMODOMOZ) Mozilla regrets keeping quiet on SSL certificate theft. Computer World, March 2011. http://www.computerworld.com/s/article/9215077/Mozilla_regrets_keeping_quiet_on_ SSL_certificate_theft?taxonomyId=82.
Stevens, M., Sotirov, A., Appelbaum, J., Lenstra, A., Molnar, D., Osvik, D., and de Weger, B. (STRV) Short chosen-prefix collisions for MD5 and the creation of a rogue CA certificate. Crypto 2009. http://eprint.iacr.org/2009/.