Page 70 – Encryption Consulting

Certificate Authorities

Introduction: The need for Certificate Authorities

In earlier articles, we have seen how digital certificates are one of the fundamental building blocks of Public Key Infrastructure (PKI). Certificates are used in multiple ways – for establishing identity, or for enabling secure web communication, or for proving ownership and integrity of software through code signing.
However, the key question that arises is: while the certificate helps to establish the reliability of some other information (such as identity or proof of ownership for software), who vouches for the reliability of the information in the certificate itself? How does a user know whether a certificate can be trusted or not and whether the public key in the certificate actually belongs to the indicated owner?

This is where a Certificate Authority or Certification Authority (CA) comes in. The CA is an entity that issues digital certificates, but does so only after performing a set of validations of the organization applying for the digital certificate – for example, confirming that the organization is the actual owner of the public key that will be included in the Digital Certificate.

Examples of some of the well-known CAs include Comodo, Symantec, GoDaddy, GlobalSign, DigiCert, Let’s Encrypt, and Entrust. CAs are at the heart of PKI as a trusted third-party entity: they are trusted both by the certificate applicants, as well as the users (devices, operating systems, browsers) who receive the certificate and decide whether to proceed with the transaction or not.

Functions of a CA

The functions of a typical CA include receiving requests for digital certificates, processing these requests including performing background verifications of the applicants, approving & rejecting the requests, actually issuing the certificates, and managing and revoking certificates. These are explained below.

Receive a Certificate Signing Request (CSR): The applicant who requires a digital certificate generates a public-private key pair and sends the public key to the CA along with basic information that is needed for the CA to issue the certificate.
Process the information in the CSR: The CA processes the information in the CSR, including the type of certificate needed and the details about the applicant company. Depending on the type of certificate needed, the CA performs a set of validations, as described in the next section.
Approve/Reject the CSR and issue the certificate: Once the validations are complete, the CA issues the certificate. The CA signs the certificate with its private key, providing a ‘seal of authenticity’ for the certificate and the public key of the certificate owner.
Manage and Revoke certificates: The CA also manages certificates – for example, renewing expired certificates based on requests from certificate owners. In case the private key of a certificate owner is compromised, the CA can invalidate or revoke a certificate. Revocation helps to alert users that the certificate cannot be trusted anymore and helps to limit the impact from a breach.

Validations performed by a CA

Any CA performs a set of validations before issuing certificates. The types of validations performed are:

Domain Validation (DV): This involves checks to make sure that the organization (or person) applying for a digital certificate (for a domain) is the actual owner (or represents the owner) of the domain name. No identity checks are performed in this case.
Organization Validation (OV): This includes additional checks (apart from domain name ownership verification) such as validating the organization itself and checking whether the applicant is authorized by the organization to apply for a certificate.
Extended Validation (EV): This involves the highest levels of validations, including detailed vetting of the company applying for the certificate such as checking the registered name of the company, place of business, and other legal details.

Trust Hierarchies & Root Certificates

Each CA has a master certificate called a Trusted Root Certificate, which is the parent of all digital certificates issued by that CA and serves as the ultimate basis of trust in the CA itself. Root certificates are typically pre-installed in the device operating system and in browsers. Root certificates are used to create intermediate certificates, these intermediate certificates are used by the CA to actually sign the digital certificates being issued by the CA.

This “chaining” of certificates to a parent going back all the way to the root certificate of that CA, is also known as a trust hierarchy or certificate hierarchy. This hierarchical approach is helpful to scale out PKI infrastructure overall – with a parent CA authorizing other CAs to issue certificates, by signing the root certificate of the other CA. Whenever needed, certificates issued by the other CA can be traced back to the root certificate of the parent CA.

CA Security

Since the CA and its root certificate are the foundation of trust for the entire PKI infrastructure, CAs need to have significantly higher levels of security as compared to any other organization. These include physical controls, logical controls, and the use of Hardware Security Modules (HSMs) for key management. In case a CA fails to meet or exceed the expected security standards, its root certificate could be removed from the system repository by browsers, operating systems, and device vendors.

This will result in an immediate warning to the end user that the certificate for the current transaction cannot be trusted and is likely to influence the user to abort the transaction, resulting in an adverse business impact. To standardize the security requirements that a CA must adhere to, industry bodies such as the CA/Browser forum have been formed.

CA/Browser Forum

This is a voluntary group of CAs and browser vendors that have come together to form an industry body with the aim of developing guidelines for CA trust systems. This includes recommendations for validation procedures, key lengths, key management, and encryption algorithms. Two major guidelines from the forum include Baseline Requirements (BRs) and Extended Validation (EV) Guidelines.

Baseline Requirements are the fundamental rules that any CA has to adhere to for issuing any type of digital certificate. EV guidelines provide additional security, technical and authentication requirements that a CA must adhere to in order to issue EV certificates.

Code Signing Certificates

Introduction

Code Signing is the process of applying a digital signature to a software program intended for distribution over the internet. Code signing helps to verify that the software is authentic i.e. from the original developer, and also helps to validate that the code has not been tampered with by an attacker while in transit e.g. by the insertion of malicious code or malware. The digital signature used for code signing is contained in a digital certificate called the code signing certificate.

Code Signing Certificates

Like any other digital certificate, code signing certificates are based on the X.509 standard and also need to be signed by a trusted third party such as a Certificate Authority (CA). However, code signing certificates cannot be used interchangeably with other certificates such as SSL certificates. The main reason for this is that as per the X.509 specification, any digital certificate contains a “Key Usage” field, which indicates the intended use of the certificate and is filled in at the time the certificate is generated. Additional information regarding the use of the certificate can also be contained in the “Extended Key Usage” extension. The X.509 specification mandates that a certificate cannot be used other than for it’s intended purpose. For example, an SSL certificate has the key usage field set to “Digital Signature” whereas a code signing certificate has the key usage field set to “Code Signing”.

While X.509 provides the specification for the certificate format, the technology implementations to generating certificates will vary by vendor. For example, Authenticode is code signing technology from Microsoft that helps developers sign applications for the Windows operating system. Authenticode certificates are used to sign files with extensions such as .exe, .dll, .ocx, .cab, and .xpi. Similarly, Apple code signing certificates are used to sign applications for iOS, Java code signing certificates are used to sign .jar files for the Java Runtime Environment (JRE), and Adobe AIR certificates are used to sign .air or .airi files.

The process of obtaining a code signing certificate is similar to other digital certificates. Any organization that wishes to publish software for distribution over the internet applies for a code signing certificate with a CA, submitting their public key and other organization information. Note that the public-private keypair needs to be separately generated, like in the case of any digital certificate. The CA validates the developer (organization) applying for the certificate, signs the certificate as proof of validation, and issues the same to the developer or software publisher. The certificate that the CA issues includes information such as the publisher identity, the public key of the publisher, the certificate validity period, the digital signature of the CA, and other details.

Types of code signing certificates

Self-signed certificates:
It is possible for software publishers to generate their own self-signed certificates. In such cases however, the signature verification process during software installation will generate a warning that the software was created by an unknown publisher. Self-signed certificates could be used for testing and local development of software, before it is made generally available for public distribution. However, self-signed certificates should not be used for production software being distributed to end users.

For public software distribution, CA issued certificates are the best option. There are two types of CA-issued code signing certificates based on the type of validation.

Standard Validation Certificates:
This is the default type of code signing certificate and involves basic validations of the publisher or developer by the CA. To be issued a standard code signing certificate, software publishers need to meet some basic requirements such as minimum key length, maximum validity period, and time stamping for digital signatures.

Extended Validation (EV) Certificates:
EV code signing certificates involve the highest levels of validations and vetting of the software publisher by the CA and are usually issued on a hardware token for additional levels of security. To be issued an EV certificate, apart from the basic requirements of standard certificates, software publishers also need to conform to much more stringent requirements – for example maintaining private keys in a Hardware Security Module (HSM) that is compliant with FIPS (Federal Information Processing Standards) 140 Level-2 or equivalent.

Certificate Expiry and Time Stamping

Like any digital certificate, code signing certificates also expire at the end of their validity period. On expiry, the signature will not be validated, and the software may cease to install or execute properly, although nothing is wrong with the software itself. This issue is addressed by the process of time stamping, in which a time stamp is applied to the code at the time of signing the file. This is usually done through another trusted third party called a Time Stamp Authority (TSA), to prove the validity and authenticity of the time stamp. The presence of a time stamp ensures that the software continues to run even though the code signing certificate has expired, giving the publisher time to renew the certificate.

Certificate Revocation

We have seen in earlier articles that the strength of Public Key Infrastructure (PKI) systems depends on how the private keys are managed and secured. If the private key for any digital certificate is compromised, the certificate needs to be invalidated, or revoked by the CA which issued the certificate. Certificate revocation is critical in the event of a breach: it ensures that end users are alerted that the certificate can no longer be trusted, discouraging the download, installation and further usage of the software. Certificate revocation is done by including the revoked certificate in a Certificate Revocation List (CRL), or by updating the certificate status using the Online Certificate Status Protocol (OCSP). Further details about CRLs and OCSP will be covered in a later article.

Overview – Digital Certificates

Overview

Public Key Infrastructure (PKI) is based on the principles of asymmetric cryptography: messages are encoded using the recipient’s public key, and the recipient decodes the message using her private key. However, how do we know that the public key we are using indeed belongs to the intended recipient? What if the public key is a forgery and belongs to an impersonator? A digital certificate helps to establish whether a public key truly belongs to the purported owner.

Just like a physical certificate of identification such as a driver’s license or a passport, a digital certificate provides information about an individual along with her/his public key and helps anybody else verify the identity of that individual. The certificate also contains one or more digital signatures, which indicate that the information in the certificate has been attested by some other trustworthy person or entity, known as a certificate authority. We will cover more about certificate authorities in a subsequent article.

Types of digital certificates

The main types of digital certificates that are used today are:

Server certificates: These implement the SSL/TLS (Secure Sockets Layer / Transport Layer Security) standards, are installed on the server, and are best known to have enabled the boom in e-commerce implementations by helping secure the communication channel between the client and server. SSL certificates in turn are of three types:
1. Domain Validation (DV) certificates: These only verify that the certificate owner has the right to use the domain name; however, they don’t certify who the owner is. Since they involve only basic validation, they are cheap and can be obtained instantly from the certificate provider. DV certificates are typically used for basic web sites and web applications.
2. Organization Validation (OV) certificates: These provide additional assurances about the certificate holder and include validations about the organization, domain ownership, and whether the applicant is authorized to apply for the certificate. OV certificates are a good option for e-commerce web sites.
3. Extended Validation (EV) certificates: These offer the highest levels of encryption and follow a strict authentication process before the certificate is issued. EV certificates are typically used by banks and financial institutions, as well as e-commerce applications.
Organization certificates: These are typically used by corporate entities and help to identify employees for secure web transactions and email communication.
Client / Personal certificates: These are “digital IDs” that help to verify an individual’s identity and also help to control the access that individuals have to information and data. In general, certificate-based authentication is far superior to a traditional User ID and password-based authentication mechanism. Personal certificates can also be used for document signing purposes. These certificates are also helpful in Business to Business (B2B) scenarios – for example, allowing suppliers and partners to access and update specific information such as shipping dates or inventory availability.
Code signing certificates: These provide the ability to digitally sign software before it is distributed, typically over the internet, for downloading. These certificates help the recipients downloading and installing software to verify that the code is from an authentic source and that it has not been altered e.g. by the insertion of malware before reaching the recipient.

The X.509 Standard

Most digital certificates today are based on the X.509 standard, defined by the International Telecommunications Union (ITU). X.509 specifies a certificate format with a standard set of fields as indicated below.

Version number: Identifies which version of the X.509 standard the certificate is based on
Public key: This is the public key of the certificate holder
Serial number: This is a unique number to identify the certificate and distinguish it from other certificates issued by the same entity.
Certificate holder’s unique identifier: This is also known as a Distinguished Name (DN) and is intended to uniquely identify the certificate holder across the internet. The DN consists of fields such as Common Name (CN), Email, Organizational Unit (OU), Organization (O), and Country (C).
Validity period: This includes the date/time when the certificate was issued, and the expiration date/time.
Issuer unique name: This is the unique name of the entity that issued the certificate, usually a Certificate Authority (CA). Using the certificate implies that you trust the CA that issued the certificate.
Issuer digital signature: This is the digital signature of the CA, generated using the private key of the CA which can be verified through the CA’s public key.
Signature algorithm: This identifies the algorithm used by the CA to sign the certificate. One example of a popular algorithm used for signing certificates is the Secure Hash Algorithm (SHA) with a hash length of 256, also known as SHA256.

Certificate Extensions

Version 3 of the X.509 standard introduced certificate extensions, which can be used to provide additional information about the subject, apart from that contained in the standard fields. Examples of such additional information include alternative subject names or information on what the certificate can be used for, such as signing a digital object. Extensions are qualified as critical and non-critical and this defines how the additional information is to be processed by the recipient.

Certificate Keys

As described earlier in this article, PKI is based on asymmetric cryptography, which uses a public-private key pair. It is important to note that this key pair is created by the requestor and not by the issuing authority such as a CA. Requestors apply for a certificate by sharing their public key with the CA. The CA includes this public key in the certificate that it issues to the requestor. Certificate holders assert their identity by proving that they possess the private key corresponding to the public key in the certificate.

Key protection and management

The most vulnerable aspect of PKI is the protection of private keys. If private keys are compromised, the entire system is compromised. Operating systems provide some basic features that can be used for key protection, an example being the Data Protection API (DPAPI) in Windows. For increased security however, one of the best practices is to use dedicated hardware appliances such as Hardware Security Modules (HSMs) and Trusted Platform Modules (TPMs).

Such dedicated hardware based key protection solutions are a good option for large organizations who manage a large number of keys. For smaller organizations however, HSMs and TPMs could be an expensive option and alternatives such as virtual appliances and cloud key management solutions could be more suitable.

Certificate stores

A certificate store is a repository used by the certificate holder to store digital certificates. This is usually a special location in the file system provided by the operating system. The Windows operating system for example, provides the following types of certificate stores:

Local Machine Certificate Store: This is local to the computer and global for all the users. It is located in the system registry under HKEY_LOCAL_MACHINE, examples being HKEY_LOCAL_MACHINESOFTWAREMicrosoftSystemCertificates and HKEY_LOCAL_MACHINESOFTWAREMicrosoftEnterpriseCertificates
Current User Certificate Store: This is local to a user account on the computer and located in the system registry under HKEY_CURRENT_USER, an example being HKEY_CURRENT_USERSoftwareMicrosoftSystemCertificates
Trusted Root CA Certificate Store: This contains the root certificates of all the CAs that are trusted by the Windows operating system. Administrators can modify the default set of trusted CAs and also manually install the root certificate of their own private CA.
Trusted Publishers Certificate Store: This contains information about code signing certificates of trusted publishers that are installed on a computer. Administrators can modify the default set of trusted publishers and manually install code signing certificates into the trusted publishers certificate store.

Code Signing – Business Benefits

Code signing is the process of applying a digital signature to any software program that is intended for release and distribution to another party or user, with two key objectives. One is to prove the authenticity and ownership of the software.

The second is to prove the integrity of the software i.e. prove that the software has not been tampered with, for example by the insertion of any malicious code. Code signing applies to any type of software: executables, archives, drivers, firmware, libraries, packages, patches, and updates. An introduction to code signing has been provided in earlier articles on this blog. In this article, we look at some of the business benefits of signing code.

Reduction in financial risk

As per recent research, the average cost of a malware attack is around $2.6 million¹ and this poses a big financial risk to any organization. One of the root causes for malware is when software is installed without verifying whether the software is authentic and without confirming who is the owner of the software.

Another source of malware attacks could be when attackers tamper with software from a source that the customer trusts and insert malicious code inside that software. Code signing addresses both these problems.
One point to note is that while code signing is necessary, it is not sufficient to prevent malware – for example, if the keys used for code signing certificates are themselves compromised. Management of keys therefore is an equally important area of focus and will be covered in a separate article.

Improved brand and reputation

Apart from the financial impact, a malware attack also results in a reputation impact, rapidly damaging organization credibility and raising questions about the security practices of any company. Code signing provides a “digital shrink wrap” seal to your software – it confirms software authenticity to your customer and warns the customer if the seal has been tampered with.

For example, even if a single bit in the software is modified, the hash used to sign the software will not match with the hash for the downloaded software – warning the customer not to install the software and thereby preventing a breach. The net effect is to improve your company’s brand and reputation in the eyes of your customers.

Increase in customer trust

Without code signing, security warnings and alerts are shown to the user by the browser and operating system – introducing an element of doubt into the user’s mind and a subsequent loss of customer trust in the software.

Customer trust can be further eroded by a malware attack, especially if the root cause analysis points to the lack of code signing being one of the reasons for the attack. Signing code is a great way of building customer confidence and trust by conveying to customers that the organization is doing whatever is possible to ensure the security and integrity of the software it is distributing.

Increasing the distribution reach and install base for your software

Online distribution of the software is becoming de-facto today considering the speed to market, reduced costs, scale, and efficiency advantages over traditional software distribution channels such as retail stores or software CDs shipped to customers. Code signing is a must for online distribution. For example, third party software publishing platforms increasingly require applications (both desktop as well as mobile) to be signed before agreeing to publish them.

Even if you are able to reach a large number of users, without code signing, the warnings shown during download and install of unsigned software are often enough to discourage the user from proceeding with the download and install. In fact, the overall trend is for operating systems to make it increasingly difficult for users to install unsigned software by asking users to go through multiple manual steps and override default security settings.

In enterprises, unsigned software can often make it to the “blacklist” or list of software prohibited by the IT team from being downloaded and installed. Code signing can address these issues, help software publishers reach a larger audience, and increase the overall download rates and install base for software.
As per a study from Accenture and Ponemon institute www.helpnetsecurity.com/2019/03/07/cyberattack-cost-2018/

PII Data Encryption – Best Practices

What is Personally Identifiable Information (PII)?

The digital age of today is powered by customer and consumer data: data is the new currency. Provided it is collected through consent and transparency, consumer data is the key for enterprises to create value for their consumers, for example through personalization and transformed experiences. Among the various attributes of consumer data are those which can be used to uniquely identify the consumer – the set of such data is called Personally Identifiable Information (PII). Examples of PII include name, email address, telephone number, address, and other attributes related with the individual’s demographic, financial, health and any other personal details.

The need for enterprises to protect PII

With regulations such as the California Consumer Protection Act (CCPA) in the USA, General Data Protection Regulation (GDPR) in Europe and similar ones in other parts of the world, enterprises are under increasing legal obligations to protect PII data. As consumer awareness increases, each data breach causes a significant dent in consumer trust and consequently, the organization’s brand and reputation. However, it’s not just about brand and reputation: recent research indicates that each data breach has a financial impact of $4 million. With threats and vulnerabilities constantly on the rise, the need for enterprises to protect PII data is more today than ever before.

Encryption of PII Data

Encryption is one of the proven ways to protect PII data. Once consumer data is encrypted, the risk of a data breach can be mitigated to a large extent, and the impact of the breach can be contained – since the stolen data will be of no use to the attacker in an encrypted form. Apart from risk mitigation, PII data encryption is also necessary from a compliance perspective, with regulations such as CCPA and GDPR mentioned earlier, mandating such encryption.

What to encrypt?

The first step in PII data encryption is to decide what data to encrypt: and data privacy regulations offer a good starting point. For example, the HIPAA (Health Insurance Portability and Accountability Act) regulations in the US defines the patient information that needs to be encrypted, including treatment information. One point to note is that while regulations indicate what data is to be encrypted, they leave the choice of the encryption technology to the enterprise.

Locating the data

Once the data to be encrypted is identified, the next step is in locating the data across the enterprise, as a part of a data discovery exercise. This is essential because PII data could be stored in multiple applications, databases, and file systems across the enterprise, or in the cloud. The data discovery exercise typically involves an application and system portfolio study or assessment, along with the use of data discovery tools.

Encryption Technologies & Standards

The next step is the actual encryption of the data. There are multiple encryption technologies and standards available and let’s take a look at the most popular ones.

Advanced Encryption Standard (AES):
AES is one of the best encryption options primarily due to its strength and widespread acceptability. As one of the strongest encryption technologies available, AES enjoys widespread acceptability across regulations, enterprises, credit card issuers, and government agencies. AES is also used in the Pretty Good Privacy (PGP) standard which is used by a large number of banking and financial services institutions. The National Institute of Standards and Technology (NIST) recommends AES as the highest standard for encryption, with three different key sizes: 128 bit, 192 bit, and 256 bits.

RSA:
This is an encryption standard named after its three inventors: Rivest, Shamir and Adleman. The strength of RSA is derived from the fact that prime factorization of very large numbers is computationally extremely difficult with existing hardware and compute resources. RSA has become popular since it can help assure the confidentiality, integrity, authenticity, and non-repudiation of data. Key lengths in RSA are very long at 1024 or 2048 bits and this is another reason for RSA’s strength. With these key lengths, the algorithm however is relatively slow and therefore one application of RSA is to use it for key encryption instead of direct data encryption. Another limitation of RSA is that as computers get more powerful, key lengths need to get longer and longer in order to stay ahead of brute force attempts at prime factorization.

Elliptic Curve Cryptography (ECC):
This is emerging as a popular alternative to RSA due to its advantages of speed, smaller key sizes, and cryptographic efficiency. ECC is also a good option for mobile devices due to its lower requirements on compute power and battery use. The algorithm is based on algebraic equations that represent elliptic curves. Keys generated through this approach are mathematically several orders of magnitude stronger than the prime factorization approach of RSA. For example, a 256 bit ECC key has the same strength as a 3072 bit RSA key.

SSL/TLS:
The Secure Sockets Layer (SSL) protocol and its successor, Transport Layer Security (TLS) have now become mainstream with web servers and browsers being a familiar example of their usage. With PII data often being sent over the network from client to server, from one application to another and from one server to another, communication channel encryption using SSL/TLS is critical to avoid “man in the middle” attacks. At the heart of SSL/TLS is a handshake protocol between the two endpoints and secured using asymmetric cryptography, which is used to generate a session key that is valid only for that communication session. The rest of the communication over the channel is encrypted using a symmetric cryptography approach, with this session key used by both endpoints. The SSL/TLS protocol ensures both security as well as performance and has become the de-facto encryption standard for data in motion not just between a web browser and server, but across any two endpoints.

Key Management:
The ultimate success of any data encryption technology does not depend on the algorithms, hardware and software used: it depends on how well the private keys used for encryption are managed. The fundamental requirement for key management is to separate the encrypted data and the encryption keys into distinct physical locations. Options for key management include Hardware Security Modules (HSM), Virtual appliances, and Cloud key management services.

Key Takeaways

Any enterprise that handles personally identifiable information (PII) of consumers is also responsible for protecting that data. Data breaches pose three significant business risks to any organization: loss of consumer trust, direct financial impact, and legal / regulatory implications and penalties. Encryption technologies offer a proven means for enterprises to protect PII data and address all three risks.

Cloud-Based VS On-Premises HSMs

Introduction

The adoption of Public Key Infrastructure (PKI) has been going up steadily in enterprises across industry sectors and has been described in earlier articles¹ . PKI mechanisms such as certificate-based authentication, encrypted communication, certificate management, code signing, and others all combine to ensure a secure enterprise. However, all the security benefits offered by PKI can come to naught if the private keys used for various purposes, are compromised. Therefore, the critical success factor (and biggest vulnerability) in PKI and any cryptography system is the safe storage and management of private keys. This is where a Hardware Security Module (HSM) comes in.

HSM Overview

An HSM is a specialized, dedicated, physical cryptographic device or ‘appliance’ designed and built for key lifecycle management – generation, storage, management and exchange of cryptographic keys. HSMs are also used for offloading of cryptographic functionality from application servers – examples being authentication, encryption, decryption, and digital signing.

HSMs offer certified mechanisms for physical and logical security, tamper resistance, intrusion prevention and detection, event logging, and secure APIs to access the HSM. HSMs allow for the segregation of the cryptographic tasks from application business logic, with unparalleled performance for any cryptographic function. For example, while software running on the best hardware might achieve a few thousand digital signatures per second, an HSM can achieve millions.

Traditionally, HSMs were set up “on-premise” or within the enterprise data center. The prevalence of cloud computing, especially over the last few years, has seen the emergence of “Cloud based HSMs” or “HSM as a Service”. Regardless of the type whether on-premise or cloud based, enterprises need to keep some of the following features in mind while selecting an HSM.

Security:

Any HSM needs to be certified to international security standards such as Common Criteria and FIPS (Federal Information Processing Standards ). Certification provides the assurance that the design and build of the device meets certain basic criteria. While certification is necessary, it is not enough, and other criteria need to be considered while selecting an HSM.

User Interface (UI):

The UI for HSM administration is often command-line based. Some providers may have a centralized management portal with a graphical user interface (GUI) and dashboard, which can ease some of the administration tasks.

Algorithms:

Any HSM should provide a number of cryptographic algorithms (both symmetric and asymmetric) that can be used for multiple functions such as authentication, encryption, decryption, signing, timestamping, and others. A related factor can be future readiness such as support for new technologies like quantum cryptography.

Automation:

Once the HSM is deployed, ongoing maintenance and management tasks take up most of the administration work. Any automation features provided by the HSM vendor can be an advantage to reduce ongoing administration efforts and costs.

Earlier articles on PKI are available in the PKI blog.

Key backup:

Backup of keys needs to be done to an environment that has similar security levels as provided by the HSM. Remote backup management and key replication are additional factors to be considered.

Integration:

The HSM is not a standalone entity and needs to work in conjunction with other applications. An important feature to evaluate therefore is the integration capabilities. Over time, since the HSM will need to support multiple applications, out-of-the box and proven integration interfaces with multiple applications can be a significant advantage.

Total Cost of Ownership (TCO):

On-premise HSMs will have a higher upfront investment or Capital Expenditure (Capex) and possibly lower annual costs. Cloud HSMs will have much lower or no Capex but may have higher annual costs or Operational Expenditure (Opex). The decision factor therefore typically is the TCO over a period of time, say five years. The cost factors to compute TCO include hardware, tools needed, network and security infrastructure, data center, operational model, payment model, software licenses, support, service levels, training, compliance, and personnel (staffing) costs.

Random Number Generation:

It is important that the HSM vendor uses an approved or certified process for Random Number Generation, since this could be a critical factor from a regulatory and compliance perspective.

Once the basic features are evaluated, the next step is to decide whether to invest in an on-premise or cloud based HSM. Some of the scenarios that can help enterprises make this decision are indicated below.

On-premise HSM

HSMs originated decades ago as physical devices that were built grounds up especially for cryptographic operations and deployed on-premise. The hardware, firmware, operating system, network access and overall functionality of an HSM were all designed to ensure that the devices were tamper-resistant and intrusion proof.

An on-premise HSM is a good option for enterprises with one or more of the following scenarios:

Large organizations which require complete and isolated control over their key management mechanisms, and who have a clear business case for the high investments needed in an on-premise HSM.
Applications which require very low latency, where an HSM being in the same data center as the application can make a big difference.
Applications with intensive cryptographic operations and a need for high performance, where offloading the cryptographic functions from an application server to a local HSM can result in a significant performance improvement for the application.
Organizations which operate in countries with strict requirements on data localization, and where cloud providers may not have a local data center in that geographic location.
Organizations with predictable workloads, where it is unlikely that the business requirements and transaction volumes will exceed the capacity of the HSM in the near future.

Cloud based HSM

A recent research report from Flexera indicates that around 94% of organizations today leverage some form of cloud services. As workloads of all types move to the cloud, HSMs are no exception. The simplicity, flexibility and agility offered by Cloud based HSMs make them an attractive value proposition, especially when enterprises face one or more of the following scenarios:

Small and medium organizations who already use a lot of cloud services and the high investments for on-premise HSMs may not be feasible.
Organizations who want to test or pilot multiple HSM services with minimal upfront investments, before committing to a vendor.
Organizations where the workloads are less and application performance and latency requirements may not require a dedicated, on-premise HSM.
Organizations with highly variable workloads which might require elasticity i.e. scaling up and scaling down of the HSM infrastructure.
Organizations who prefer a predictable, operational expenditure (Opex) based financial model offered by the cloud rather than high upfront capital investments needed by an on-premise HSM.

There are two types of cloud based HSMs: public cloud based, and third party. Both types offer the HSM-as-a-Service model. Depending on the vendor, both types may also offer single tenant as well as multi-tenant solutions, and additional key management services apart from HSMs. The main difference between the two cloud based HSMs is vendor lock-in.

Public cloud based HSMs are typically tied to that public cloud provider such as AWS or Azure and are therefore suitable for enterprises which leverage only one public cloud provider. Third party cloud based HSMs usually work across multiple public cloud providers and therefore are a good choice for enterprises which have multi-cloud scenarios².

Third party cloud HSMs, being specialized offerings, may also have more sophisticated features such as automation, scaling, back-ups, and better administration. In general, the choice of a cloud based HSM is closely linked with the enterprise cloud strategy.

Key Takeaways

The question “Which is a better option: an on-premise HSM or a cloud based HSM?” has no single answer. Enterprises will need to choose the best option depending on their use cases and business scenarios. One thing however remains clear: the benefits offered by Public Key Infrastructure (PKI) can be completely undermined if private keys are compromised. Protecting and managing those keys is therefore a critical requirement to ensure enterprise security. HSMs, whether on-premise or cloud based, are the best options today to fulfil that requirement.

A recent research report on cloud trends from Flexera indicates that more than 80% of organizations are moving to multi-cloud environments

IoT PKI

Internet of Things (IOT)

Driving Digital Transformation

The Internet of Things (IOT) has been one of the major technology drivers of Digital Transformation in the world over the last few years, across industry sectors. The number of connected devices already exceeds the number of human beings on the planet, and research indicates that we are likely to see around 50 billion connected devices over the next five years making up the smart, connected planet.

The applications of IOT range from smart homes, smart buildings, smart cities, connected vehicles, smart manufacturing, smart retail, medical devices in healthcare, fitness/wellness trackers, wearable devices, and more. With the rollout of related technologies such as 5G and Internet Protocol (IP) version 6, which are designed to support billions of connected devices, IOT as a technology is all set to play a pivotal role in our digital future.

Need for IOT security

As worldwide IOT adoption goes up, the risk of security breaches also goes up – since each of those billions of connected devices could be vulnerable to an attack. Also, considering the scale of IOT deployments, the economic impact of IOT security breaches will also be felt at a proportionately massive scale.

Likewise, one worrying trend is that vast numbers of connected devices do not have adequate security safeguards and are vulnerable to breaches. Some of the key security risks in IOT deployments include attackers using a connected device as an entry point into the network, introducing malware to alter the function of the device, controlling the device remotely, or tapping into data from the device.

Apart from the economic impact, the nature of IOT technology is such that physical security of individuals as well as organizations can be at risk. For example, altering the function of a device could have physical security implications: a CCTV camera that appears to be working fine, but is showing a “dummy image” instead of the real view, resulting in a threat of a physical intrusion into a home or company premises.

How and why PKI is becoming essential for IOT security?

We have seen in earlier articles how Public Key Infrastructure (PKI) is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption. Recent research from Ponemon Institute indicates that over the last few years, IOT is becoming a major driver for PKI adoption. The percentage of respondents who believe that IOT is the most important technology trend driving PKI adoption has nearly doubled to around 41%. The research also predicts that more than 40% of IOT devices in use by 2021 will primarily rely on digital certificates for identification and authentication.

The primary reason why IOT security is becoming synonymous with PKI is scale. As mentioned earlier in this article, most predictions indicate more than 50 billion connected devices on the planet over the next few years. Even a single compromised device can have an enormous security impact – it is difficult to comprehend the scale of impact if many devices are compromised.

Connected devices interact with each other through machine to machine (M2M) communication. Each of these billions of interactions will require authentication of device credentials for the endpoints to prove the device’s digital identity. In such scenarios, an identity management approach based on passwords or passcodes is not practical, and PKI digital certificates are by far the best option for IOT credential management today.

IOT devices will also need regular patches and upgrades to their firmware, with code signing being critical to ensure the security of the downloaded firmware – another example of the close linkage between the IOT world and the PKI world.

Certificate management for connected devices, including revocation of expired certificates, is another example where PKI can help to secure IOT devices.

In some sectors such as healthcare and wellness, IOT devices might collect personally identifiable information (PII). With government regulations worldwide mandating secure transit (and storage) of PII data, PKI can help ensure compliance with the regulations by securing the communication channel between the IOT device and the gateway.

Key Takeaways

The proliferation of connected devices today, projections for billions of devices in the next few years and the continued growth in the number of applications across industry sectors is an indicator of the enormous promise of the Internet of Things (IOT). This promise however could be undermined by the lack of adequate security safeguards with IOT devices. PKI provides some of the best options for IOT security including device identity management, code signing for device firmware, and encrypted communication between devices and other endpoints such as IOT gateways.

Enterprise applications and PKI – Part 2

PKI in the Enterprise: Additional Use Cases You Should Know

In the previous article, we explored the importance of Public Key Infrastructure (PKI) from an enterprise architecture perspective. We also saw some of the typical enterprise application scenarios that need to use PKI, including public facing web sites and web applications, Virtual Private Network (VPN) services, mobile applications and software (code signing). This article illustrates a few of the other enterprise application scenarios where PKI needs to be an integral part of enterprise architecture.

Summary
In today’s world, enterprise application architecture needs to follow a “Security First” approach. For example, with cloud technology becoming mainstream, cloud security also needs to become a top priority for enterprises.

Similarly, for application authentication, enterprises can no longer rely on just a username and password approach, since enterprise applications are accessed anytime and from anywhere. Threats like phishing have resulted in email security becoming a hygiene factor and not just a “good to have”. Digital signatures for documents have become the norm, replacing manual signatures.

Overall, enterprise architecture today requires application security to keep three needs in mind: stronger authentication mechanisms, validation of the device or endpoint that is being used to access the application and securing the communication channel between the application and the endpoint. PKI through digital certificates, provides a way for enterprises to address all three of these needs. This also means that enterprises need to think about good certificate management practices, including the set up of a private certificate authority (CA) where needed. That, however, is a different subject and will be covered in a future article. Stay tuned!

Key Business Drivers for Encryption Adoption

Understanding the Business Case for Encryption

The human desire for privacy in communication is perhaps as old as the desire for communication itself. The scrambling of messages through encryption, into a form that only the intended recipient can understand, has been going on for centuries, with Julius Caesar’s cipher being one of the most cited early examples. A lot has changed since then, but in today’s digital, connected world the need for encryption is as strong as ever. This is reflected in the widespread adoption of encryption technologies and solutions in enterprises across the world. What are some of the business drivers for enterprises to adopt encryption? This article explores some of the important ones.

Business Drivers to adopt Encryption

Protecting sensitive/classified information: Every company deals with sensitive and confidential data. This could be their own data, such as information related to their core Intellectual Property (IP) or their contracts with customers and partners. This could also be as a custodian of sensitive data that has been shared with them by a customer or partner – an example being personally identifiable information (PII) of customers for enterprises which are in the Business to Consumer (B2C) space. Protecting such sensitive and confidential data is of paramount importance for any business and this is where encryption plays a key role.
Compliance with data privacy security regulations & standards: Europe’s General Data Protection Regulation (GDPR), which came into force in May 2018, is a well-known example of how legislations are being put in place for data protection and privacy. In the US, data privacy laws are usually sector and state specific, an example being the California Consumer Privacy Act (CCPA) of 2018¹. Another example is the Payment Card Industry Data Security Standard (PCI DSS) for the financial services industry, which is applicable globally. The encryption of consumer data is one of the fundamental requirements for all these regulations, with both in-transit data as well as data at rest being covered within the scope for encryption. While the choice of encryption algorithms, technologies and vendors is left to the enterprise, non-compliance can lead to significant penalties, especially in the event of data breaches.
Protection against known threats: There are several known threats to data security that exist today. An example could be the threat to data stored on the cloud. As enterprises move more and more data to the cloud, the risk of breaches increases since the data no longer resides within the organization’s physical boundaries and network security perimeter. It is not enough to depend only on the cloud service provider’s data security mechanisms. Enterprises need to have their own cloud data encryption strategy in place. Companies can choose to encrypt data on-premise before sending it to the cloud, or encrypt the data after it moves to cloud, using technologies and compute power from the cloud provider². Another example of known threats could be at an application and application programming interface (API) level. Enterprise applications as well as APIs exposed to the outside world are always vulnerable to attack. It is critical that any interfaces and communication channels these applications have with the external world are protected using encryption protocols such as Secure Sockets Layer (SSL) and its newer version Transport Layer Security (TLS). As a third example, attacks on databases for such applications (or independent data stores maintained by the enterprise) are another known threat. Database security through encryption can be implemented at three levels – encryption of any configuration files with database access information (e.g. those used by web and application servers), encryption of the data stored in the database, and sometimes encryption of the entire file system where the database is stored.
Limiting the liability of data breaches: Whatever the precautions, it is a fact that data breaches can happen – any enterprise that believes otherwise is living in a fool’s paradise. The fallout of data breaches can be significant, and the resulting liabilities can be enormous. Apart from the financial and legal liabilities of data breaches, enterprises also must deal with the reputational damage and the loss of customer trust. Strong encryption mechanisms applied to sensitive data in the enterprise can ensure that even in the event of a data breach, the stolen data cannot be used by the attackers. While these are some of the key business drivers for enterprises to adopt encryption today, must be noted that encryption alone is not a ‘silver bullet’ solution to all data threats. For example, insider threats account for a large number (reports vary between 60% – 75%) of data breach incidents. If insiders have access to encryption keys and once those keys are compromised, not much can be done. That’s why Enterprise Key Management goes hand-in-hand with any effective enterprise encryption strategy. And similarly, Encryption should be addressed as a part of a larger, holistic solution to implementing cyber security in the enterprise.

A comparison between the CCPA and GDPR is available in an earlier blog, available at this link: CCPA vs GDPR

In either scenario, key management becomes an important issue – but that is out of scope for this article and will be covered in a future topic

Enterprise applications and PKI – Part 1

Using PKI to Secure Critical Enterprise Applications

In an earlier article, we defined Public key infrastructure (PKI) as a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption. We also identified some of the trends in digitalization which have been driving the adoption of PKI. As the adoption of PKI increases, enterprises need to understand which of their applications need to be “PKI enabled”. In other words, enterprise architectural blueprints should clearly identify the application scenarios to use PKI, and also flag non-conforming scenarios as potential security risks. In this article, we look at some of the typical application scenarios leveraging PKI in order to protect the enterprise and lower its risk profile.

Public facing websites and web applications: The padlock symbol in the URL bar of any web browser is now a de-facto requirement for any public facing website and application. The padlock represents an SSL/TLS (Secure Sockets Layer / Transport Layer Security) encrypted connection between the browser and the website that is set up using a digital certificate being sent from the website or web application server to the browser. The certificate confirms the identity of the website or web application to the browser. How does the browser know whether the certificate itself is valid and genuine? It verifies that the certificate has not yet expired and has been issued and ‘signed’ by a trusted third party, called a Certificate Authority (CA). Once the certificate is verified, the browser sends its public key across to the server, which uses this to encrypt the data that is sent back to the browser. The browser decrypts this data using its private key. All this magic happens seamlessly in the background, courtesy of PKI.
Virtual Private Network (VPN) services: The need to access an enterprise network remotely (for example from a different office location or a partner location) has existed for quite some time. The typical solution for this need is a leased line – a dedicated physical line between the remote location and the enterprise network. However, the leased line approach is not feasible for individual remote workers who need to access the enterprise network, such as employees who need to work from home. This is where VPN services, with the ability to provide a secure, encrypted communication channel for access to the enterprise network over the internet, have become extremely popular.
When a remote user accesses the enterprise network through a VPN, a single authentication mechanism for example with a username and password is not secure enough. Multi-factor authentication (MFA) is important – with one of the authentication mechanisms being a digital certificate. The VPN channel (or ‘tunnel’) is set up only once the certificate validation is completed, as described earlier in this article.
Mobile applications: With every member of the workforce carrying at least one mobile device (and often more than one) and distributed teams (“work from anywhere”) becoming increasingly common, Enterprise mobility is on the rise. Mobile Device Management (MDM) platforms address some of the requirements of enterprise mobility by providing the ability to provision devices, manage mobile applications, and enforce the enterprise security policy on the device. However, authentication of mobile devices and users remains a challenge. An approach solely based on username and password is just not secure enough and the best way to ensure user identity. Mobile device validation and encrypted communication between the device and the enterprise network, using digital certificates is a far superior approach. Both the main mobile operating systems today i.e. iOS and Android, offer native support for digital certificates.
Software applications:Code signing: Companies who need to distribute software and the associated upgrades and patches to their customers, partners or employees usually do so today over the internet¹ . This however has brought new challenges to the forefront. Earlier, software that was distributed on physical media such as compact discs (CDs) was shrink-wrapped i.e. packaged in a box and physically sealed. Any tampering with the packaging and seal helped to alert the user. However, when the software is distributed over the internet, how does a user know whether the software (s)he is downloading is from the actual author? How does the user know that the software has not been tampered with and some malicious code or malware inserted into it? Code signing provides the answer to these questions. Any company that wishes to distribute software over the internet uses a code signing certificate to digitally sign the software. At the client side, the browser being used for the software download and the operating system (OS) on which the software is being installed, validate the code signing certificate and verify its authenticity. If the software has been tampered with, the user is alerted immediately. Without code signing, depending on the browser security settings, the user might get an alert, or the software may not get downloaded at all. If the user ignores the warning, downloads the software and attempts to install it, (s)he gets another warning, this time from the OS, that the publisher of the software could not be verified. As a result of these warnings, users may choose to abort the download, or abort the installation of the software – which is why it is important for companies to ensure that they sign the software that they publish. These are some of the enterprise application scenarios that need to use PKI. There are a few others – these will be covered in part 2. Stay tuned!

Over the years, the sales and distribution of software CDs (compact discs) has declined significantly, with the internet becoming the primary means for software to be distributed to end users.