What is Code Signing?

Code signing is the process of authenticating software code/application/program/scripts to confirm the source of origin of the publisher and assure that the code has not been tampered or altered since it was signed.

Certificate Authorities (CA) confirm code signing source identity and bind their public key to a code signing certificate. This certificate enables validation of code sign with an authentic root certificate. Performing code sign will cater below three functions:

  • Provides authentication of code
  • Provides cryptographic protection
  • Software/code author validation


CodeSign Secure's free demo

Top 5 benefits of “Code Signing”:

Let us take a look into the top 5 benefits users can enjoy by using “Code signing”:

  1. Validates code integrity: Code signing provides integrity check of the code using hash function. Hash function is used at the source to sign the code and the same hash has to be matched at the destination. This provides proof of code integrity. If the hash is not matched, users would either receive a security warning or code will fail to download.

    Verification can be performed using timestamp as well. Code signing certificates might include optional time stamp. Time stamp data strip is included along with signature during the time of signature. This process ensures the validity of certificate at the time of signature.

  2. Issuing company reputation and authenticity:Using code signing process for authentication and validation of software, code and/or programs eliminates the risk of program corruption and tampering. This will safeguard the company’s reputation as well as intellectual property.

    Enhancing trust on both sides of the transaction, companies can be more benefitted with customers trusting their software programs, files etc. for download. With increase in reputation one can expect considerable increase in customer loyalty.

  3. Increase in revenue:Now a days, software publishers and network platform provides are increasingly mandating code signing process from a trusted source/certificate authority (CA) for distribution of software among users.

    This is even more beneficial for small companies or individual developers to gain trust among customers through authenticity and increase their brand presence as well as revenue.

  4. Safe and secure user experience:As already discussed in one of the points mentioned above, Code signing process builds mutual trust amongst both the parties i.e. vendor as well as consumer. On top of it, customers who use code signed software or files can be sure of security as the code is properly authenticated and validated which prevents code tampering.

    Also, using code signing provides smooth user experience as there will be minimized security warnings and installation failures when code is signed by trusted certificate authority.

  5. Seamless integration with multiple platforms:Code signing process is now available on multiple platforms such as Apple iOS, Windows, Linux, Android, JAVA, Adobe AIR etc. Many of these platforms highly recommend code signing process for code distribution.

    Many browsers would require code signed using certificate from trusted certificate authority and reject any action commands provided through untrusted sources. One interesting fact is, Microsoft office macros and Firefox browser extensions also require code signing.

If your organization is looking for implementation of Code signing, please consult info@encryptionconsulting.com for further information

About the Author

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

Read time: 5 mins

Encryption is a process that takes plaintext as input and transforms it into an output (ciphertext) that reveals no information about the plaintext. Encryption adds a layer of defense for protecting data and ensures that if the data accidentally falls into an attacker’s hands, they cannot access the data without having access to the encryption keys. Even if an attacker obtains the storage devices containing your data, they will not be able to understand or decrypt it.

Data Encryption Options

Cloud storage encrypts data on the server-side before it is written to disk, at no additional charge. Besides this standard, there are additional ways to encrypt the data while using Cloud Storage.

Below are the available encryption options for Google Cloud:

Server-side encryption

Google Cloud Storage performs server-side encryption by default on all uploaded objects. All data is broken into chunks which can be up to several GB in size. Using envelope encryption, each chunk of data is encrypted with a unique Data Encryption Key (DEK) that is also encrypted with a Key Encryption Key (KEK). The encrypted version of the DEK is then stored alongside the encrypted data, and the encrypted chunks of data are distributed across Google’s storage systems

Google Cloud Storage supports server-side encryption with two key options:
Customer-supplied encryption keys

With the customer-supplied encryption key (CSEK) option, users must generate their own AES 256
symmetric key and provide it to google cloud storage for encryption/decryption operations. The CSEK is only stored in storage system memory and never persisted on any Google Cloud device

Cloud storage does not permanently store user’s key on Google’s servers or otherwise manage user’s key. Instead, the user provide key for each cloud storage operation, and the key is purged from Google’s server after completion of the operation. The customer-supplied encryption key is hashed and then purged from the storage system. The cryptographic hash is used to validate (future requests) but cannot be used to decrypt data or to reconstruct a key When the customer supplies the encryption key, cloud storage uses the key while encrypting

  • the object data
  • the object’s checksum
  • the object’s hash

Cloud Storage uses standard server-side keys to encrypt the remaining metadata for the object, including the object’s name.Encryption and Decryption workflow mentioned below:

  1. The CSEK is provided to Google Cloud Storage along with the data upload
  2. Data is broken into sub-file chunks
  3. A Google Cloud Storage system calls a common cryptographic library that Google maintains, called CrunchyCrypt, to generate a unique, one-time key called DEK
  4. Each data chunk is encrypted using a DEK
  5. The storage system then uses the CSEK as the KEK and encrypts the DEK
  6. The encrypted DEK is stored alongside the ciphertext chunk it encrypted in Google Cloud Storage while the plaintext version of the DEK is deleted from memory
  7. The customer-supplied encryption key is hashed and then purged from the storage system. The cryptographic hash is used to validate future requests but cannot be used to decrypt data or reconstruct the key
  8. The client or application requests data from Google Cloud Storage while supplying the CSEK
  9. Google Cloud Storage identifies the chunks in which the data is stored and where the chunks reside and retrieves the chunks
  10. For each data chunk, the storage system retrieves the encrypted DEK and decrypts it using the CSEK
  11. Once the decryption is done using DEK, the storage system discards the DEK and sends the decrypted data to the client or application that requested the data


Move your IT infrastructure to Cloud.

Customer-managed encryption keys:

Customer-managed encryption keys are keys generated for users by Cloud Key Management Service (KMS), that the user manages themselves. These keys act as an additional encryption layer on top of the standard Cloud Storage encryption.The encryption and decryption workflow:

  1. Data is broken into sub-file chunks after being uploaded to Google Cloud
  2. A Google Cloud Storage system calls a common cryptographic library that Google maintains, called CrunchyCrypt, to generate a unique one-time use DEK
  3. Each data chunk is encrypted using a DEK
  4. The storage system then sends the DEK to Google’s Key Management Service (KMS) to be encrypted using that storage system’s associated Key Encryption Key (KEK)
  5. The encrypted DEK is stored alongside the ciphertext chunk it encrypted in Google Cloud Storage while the plaintext version of the DEK is deleted from memory
  6. When data is requested, Google Cloud Storage identifies the chunks in which the data is stored and where the chunks reside and retrieves the chunks
  7. For each data chunk, the storage system retrieves the encrypted DEK and sends it to Google’s KMS for decryption
  8. KMS sends the decrypted DEK to the storage system where it is used to decrypt the data
  9. The storage system discards the DEK and sends the decrypted data to the client that requested the data

Client-side encryption:

With this option, Users create and manages its own encryption keys. Users must encrypt the data before sending it to cloud storage. The encrypted data on the client side arrives at cloud storage in an encrypted state. When cloud storage receives the data, one more time the data will be encrypted. This second encryption is called server-side encryption, which Cloud Storage manages. While retrieving the data, cloud storage removes the server-side layer of encryption, but user must decrypt the client-side layer by themselves.

Benefits

Customer-managed keys provide the following benefits:

  • More Control over Data Access:
    • Customer-managed keys provide an extra level of security for customers with sensitive data.
    • When the customer decides to disable access, data can no longer be decrypted
  • Stop Data Breaches:
    • In this case, disabling customer-managed keys will allows customers to stop ongoing exfiltration of their data
  • More Control over Data Lifecycle:
    • Using customer-managed keys, sensitive data is encrypted with the customer’s key. Without customer’s/users consent no one can decrypt the data
    • The customer has full control over the data’s lifecycle
  • Secure
    • Compute assets are encrypted using the industry-leading AES-256 standard, and Google never retains users’ keys, meaning Google cannot decrypt user’s data at rest.
  • Comprehensive
    • Customer-Supplied Encryption Keys cover all forms of data at rest for Compute Engine, including boot and data persistent disks.
  • Fast
    • Google Compute Engine is already encrypting user’s data at rest, and Customer-Supplied Encryption Keys gives user greater control, without additional overhead.

About the Author

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

Microsoft Azure Services

  • Master Key Types: Microsoft Azure offers 2048, 3072, and 4096 bit RSA asymmetric master keys, but it does not support any symmetric master keys.
  • Encryption Modes: Microsoft Azure does not offer symmetric encryption methods, but does offer two asymmetric encryption methods: RSA OAEP and RSA PKCS#1v1.5.
  • Plaintext Size Limits: Microsoft Azure offers a plaintext size limit of 0.25KB.
  • Bring Your Own Key (BYOK) Options: To utilize BYOK, the key being used on the cloud must first be imported the Cloud Service Provider, and to import the key, it must first be wrapped. Microsoft Azure takes an RSA key that is wrapped by AES and RSA-OAEP. 
  • Signature Modes: To ensure the integrity of data-in-transit, signatures are used. Microsoft Azure offers RSA-PSS, RSA PKCS#1V1.5, ECDSA with P-256, ECDSA with P-512, ECDSA with SECP-256k1. and ECDSA with P-384 signature methods.
  • Cloud HSM Compliance: Each Cloud Service allows users to store keys in a cloud HSM, but the cloud HSM for each service has different compliancy certificates. Microsoft Azure’s regular Vault HSM is FIPS 140-2 level 2 compliant and its Managed HSM is FIPS 140-2 level 3 compliant.
  • Azure Key Vault Features: Azure Key Vault protects keys and secrets with HSMs or software appliances. Both Azure Services and the customer can access the keys and secrets that are stored. Azure Key Vault is FIPS 140-2 Level 2 compliant and only supports asymmetric keys. It also supports RSA keys of sizes 2048, 3072 and 4096and Elliptic Curve key types P-256, P-384, P-521, and P-256K (SECP256K1). Azure Key Vault supports customer managed keys and manages tokens, passwords, certificates, API keys, and other secrets.
  • Azure Dedicated HSM Features: Azure Dedicated HSM stores keys on an on-premises Luna HSM. This key storage is only accessible by the customer, allowing users to manage keys and not have to worry about the CSP having access to the keys. Azure Dedicated HSM is FIPS 140-2 Level 3 compliant and supports symmetric and asymmetric keys. It also supports RSA, DSA, Diffie-Hellman, Elliptic Curve Cryptography (ECDSA, ECDH, Ed25519, ECIES) with named, user-defined, and Brainpool curves, and KCDSA for asymmetric keys. Symmetric keys created with AES-GCM, Triple DES, DES, ARIA, SEED, RC2, RC4, RC5, and CAST are accepted by Azure Dedicated HSM. For Hash/Message Digest/HMAC, SHA-1, SHA-2, and SM3 are accepted, for key derivation SP800-108 Counter Mode is accepted, and for key wrapping SP800-38F is accepted. Azure Dedicated HSM is capable of offline key backup, and single device provisioning, but customer managed keys are not supported.

About the Author

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

Amazon Web Services (AWS)

  • Master Key Types: Amazon Web Services (AWS) offers 2048, 3072, and 4096 bit RSA asymmetric master keys.  It is also one of the only Cloud Service Providers (CSPs) to offer 256 bit symmetric master keys.
  • Encryption Modes: AWS offers symmetric AES GCM and asymmetric RSA OAEP encryption methods.
  • Plaintext Size Limits: Amazon Web Services offers a plaintext size limit of 4KB.
  • Bring Your Own Key (BYOK) Options: To utilize BYOK, the key being used on the cloud must first be imported the Cloud Service Provider, and to import the key, it must first be wrapped. Amazon Web Services takes an AES-256 key that is wrapped by RSA 2048. 
  • Signature Modes: To ensure the integrity of data-in-transit, signatures are used. AWS offers RSA-PSS, RSA PKCS#1V1.5, ECDSA with P-256, ECDSA with P-512, ECDSA with SECP-256k1. and ECDSA with P-384 signature methods.
  • Cloud HSM Compliance: Each Cloud Service allows users to store keys in a cloud HSM, but the cloud HSM for each service has different compliancy certificates. Amazon Web Services regular KMS HSM is FIPS 140-2 level 2 compliant and the AWS Custom Keystore CloudHSM is FIPS 140-2 level 3 compliant.
  • Amazon KMS Features: AWS KMS has a managed service in AWS cloud for key storage. Both customers and AWS services can access keys stored in this way. AWS KMS is FIPS 140-2 Level 2 compliant and supports symmetric and asymmetric keys. It also supports RSAES_OAEP_SHA_1 and RSAES_OAEP_SHA_256 encryption algorithms with RSA 2048, RSA 3072, and RSA 4096 key types. Encryption algorithms cannot be used with the elliptic curve key types (ECC NIST P-256, ECC NIST P-384, ECC NIST-521, and ECC SECG P-256k1). When using elliptic curve key types, AWS KMS supports the ECDSA_SHA_256, ECDSA_SHA_384, and ECDSA_SHA_512 signing algorithms. AWS KMS is capable of limited key management, storage and auditing, and encryption.

 

  • Amazon CloudHSM Features: AWS CloudHSM has a dedicated hardware appliance in AWS cloud for key storage. This key storage is only accessible by the customer, allowing users to manage keys and not have to worry about the CSP having access to the keys.
    AWS CloudHSM is FIPS 140-2 Level 3 compliant and supports symmetric and asymmetric keys. It also supports 2048-bit to 4096-bit RSA keys, in increments of 256 bits, 128, 192, and 256-bit AES keys, 3DES 192-bit keys, and keys with the P-224, P-256, P-384, P-521, and secp256k1 curves. Only the P-256, P-384, and secp256k1 curves are supported for sign and verify.
    AWS CloudHSM is capable of key management, key storage and auditing, and being provided as the root of trust for PKIs.

About the Author

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

Google Cloud Platform (GCP) Services

  • Master Key Types: Google Cloud Platform (GCP) offers 2048, 3072, and 4096 bit RSA asymmetric master keys.  It is also one of the only Cloud Service Providers (CSPs) to offer 256 bit symmetric master keys.
  • Encryption Modes: GCP offers symmetric AES GCM and asymmetric RSA OAEP encryption methods.
  • Plaintext Size Limits: Google Cloud Platform offers a plaintext size limit of 64KB.
  • Bring Your Own Key (BYOK) Options: To utilize BYOK, the key being used on the cloud must first be imported the Cloud Service Provider, and to import the key, it must first be wrapped. Google Cloud Platform takes an AES-256 key that is wrapped by RSA 3072. 
  • Signature Modes: To ensure the integrity of data-in-transit, signatures are used. GCP offers RSA-PSS, RSA PKCS#1V1.5, ECDSA with P-256, and ECDSA with P-384 signature methods.
  • Cloud HSM Compliance: Each Cloud Service allows users to store keys in a cloud HSM, but the cloud HSM for each service has different compliancy certificates. All HSM keys on Google Cloud Platform are FIPS 140-2 level 3 compliant.
  • Google Cloud KMS Features: Google Cloud KMS can store keys in either an HSM or a software application. This key storage can be accessed by both the customer and the CSP. Google Cloud KMS is FIPS 140-2 Level 3 compliant if an HSM is used, and FIPS 140-2 Level 1 compliant if software keys are used. Google Cloud KMS supports symmetric and asymmetric keys. It also supports 256-bit Advanced Encryption Standard (AES-256) keys in Galois Counter Mode (GCM), padded with Cloud KMS-internal metadata and RSA keys of sizes 2048, 3072 and 4096.Google Cloud KMS is capable of key management, storage, auditing, encryption, encryption for Kubernetes, and both HSM and software key management.

About the Author

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

Crypto-Agility
Table of Contents

Often in the cybersecurity field, encryption algorithms are broken or deemed to be too weak, and so the industry standards shift to a new algorithm. This switch can damage existing hardware that previously relied upon the deprecated encryption algorithm, unless that security system is cryptographically agile. Cryptographic agility refers to the ability of security hardware to change to a new algorithm, as per industry standards, without the need to rewrite applications or deploy new hardware systems.

Crypto-agility comes about when an infrastructure has such complete control over their cryptographic operations that a change to those operations will not impact the day to day functions of the hardware in any way. As time has gone on, computer systems have become more complicated, as have encryption algorithms and attackers methods of attacks, in turn. Since attackers are learning to break algorithms, new ones must be devised regularly. Thus, crypto-agility has become a necessity with newly developed hardware systems.

Why is Crypto-Agility Important?

As previously mentioned, attackers breaking encryption algorithms is one of the main reasons those algorithms are replaced. Attackers are discovering new ways to crack secure algorithms used every day. In 2018, the National Institute of Science and Technology (NIST) released a guideline that brought attention to the fact that the Sweet32 vulnerability was used to make the encryption algorithm 3DES insecure. 3DES is used in the financial sector by most companies, so changing from 3DES to a new encryption algorithm could break the hardware used in the financial sector, if it is not cryptographically agile. As time goes on, vulnerabilities are bound to be found in all types of encryption, so crypto-agility will continue to grow in most organization’s hardware devices.

Another reason to ensure an IT infrastructure is cryptographically agile is because of the emergence of quantum computing. Quantum computing is an emerging side of computer science that is being more and more heavily researched each year, as quantum computing has the potential to be able to render all classical computing cryptosystems useless. Quantum computing will continue to grow for the foreseeable future, and so certain crypto-agility techniques must be implemented. Future computing systems will need to be able switch between multiple encryption algorithms, as opposed to just one, to combat quantum computing.

How to achieve and maintain Crypto-Agility

The most important part of creating cryptographically agile hardware systems is by planning for it at the beginning. When the designs for your security systems are initially made, ensure that crypto-agility is one of the main requirements. This will ensure that the cryptographic agility of the hardware is being monitored at all times. With existing systems, there is software that exists that can implement crypto-agility, as recreating the systems from the bottom up is not feasible.


Highly Secure and Reliable PKI for your Organization

Another method to achieve crypto-agility is by implementing policies that tell employees the proper procedures to follow to reach and maintain crypto-agility. These policies should be detailed, but not too technical, to allow employees from any sector to be able to understand the policies. The policies should also be clear and enforce the use of the most up-to-date cryptography methods. Everyone within the organization should be trained in the use of all policies, especially crypto-agility related ones. These policies should be where the role-based access controls are discussed as well.

IT security teams should train the different sectors of the company on the responsibilities of that sector to help reach the goal of crypto-agility. The sector responsibilities for all parts of the organization should include maintaining an accurate inventory of crypto assets, noting the current access level of each member of the sector, and keeping track of who owns what data. This will assist IT security team members in maintaining crypto-agility throughout the organization.

Public Key Infrastructures (PKIs) are another great method to attaining crypto-agility. A PKI deals with the management of certificates and keys, and automates the replacement, creation, and rotation of keys and certificates. This removes the issue of human error from the management of keys and certificates. You also gain control over the Chain of Trust and Certificate Authorities (CAs) utilized in the PKI, gaining your organization the ability to have even more control over the encryption of data.

The following best practices will help reinforce the methods used to attain crypto-agility:

  • Automation of management and tracking in as many sectors as possible
  • Maintain strong visibility of all processes, assets, and user-usage throughout the organization
  • Identify and fix vulnerabilities before data can be stolen or compromised
  • Update with the patches for hardware and software as often as possible, to remain up-to-date on security breaches
  • Ensure the ability to test and replace current encryption algorithms with newly created algorithms is available
  • Replace keys and certificates as soon as necessary
  • Keep up with the most current encryption algorithms available

About the Author

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

Federal Information Processing Standards (FIPS)
Table of Contents

Keeping sensitive data, such as Personally Identifiable Information (PII), secure in every stage of its life is an important task for any organization. To simplify this process, standards, regulations, and best practices were created to better protect data. The Federal Information Protection Standard, or FIPS, is one of these standards. These standards were created by the National Institute of Science and Technology (NIST) to protect government data, and ensure those working with the government comply with certain safety standards before they have access to data. FIPS has a number of standards released, but this article discusses FIPS 140-2.

What is FIPS 140-2?

FIPS 140-2 is a standard which handles cryptographic modules and the ones that organizations use to encrypt data-at-rest and data-in-motion. FIPS 140-2 has 4 levels of security, with level 1 being the least secure, and level 4 being the most secure:

    • FIPS 140-2 Level 1- Level 1 has the simplest requirements. It requires production-grade equipment, and atleast one tested encryption algorithm. This must be a working encryption algorithm, not one that has not been authorized for use.
    • FIPS 140-2 Level 2- Level 2 raises the bar slightly, requiring all of level 1’s requirements along with role-based authentication and tamper evident physical devices to be used. It should also be run on an Operating System that has been approved by Common Criteria at EAL2.
    • FIPS 140-2 Level 3- FIPS 140-2 level 3 is the level the majority of organizations comply with, as it is secure, but not made difficult to use because of that security. This level takes all of level 2’s requirements and adds tamper-resistant devices, a separation of the logical and physical interfaces that have “critical security parameters” enter or leave the system, and identity-based authentication. Private keys leaving or entering the system must also be encrypted before they can be moved to or from the system.

 

  • FIPS 140-2 Level 4- The most secure level of FIPS 140-2 uses the same requirements of level 3 and desires that the compliant device be able to be tamper-active and that the contents of the device be able to be erased if certain environmental attacks are detected. Another focus of FIPS 140-2 level 4 is that the Operating Systems being used by the cryptographic module must be more secure than earlier levels. If multiple users are using a system, the OS is held to an even higher standard.


Enhance Your Existing Infrastructure

Why is being FIPS 140-2 compliant important?

One of the many reasons to become FIPS compliant is due to the government’s requirement that any organization working with them must be FIPS 140-2 compliant. This requirement ensures government data handled by third-party organizations is stored and encrypted securely and with the proper levels of confidentiality, integrity, and authenticity. Companies desiring to create cryptographic modules, such as nCipher or Thales, must become FIPS compliant if they want the vast majority of companies to use their device, especially the government. Many organizations have developed the policy of becoming FIPS 140-2 compliant, as it makes their organization and services seem more secure and trusted.

Another reason to be FIPS compliant is the rigorous testing that has gone into verifying the strength behind the requirements of FIPS 140-2. The requirements for each level of FIPS 140-2 have been selected after a variety of tests for confidentiality, integrity, non-repudiation, and authenticity. As the government has some of the most sensitive information in the nation, devices, services, and other products used by them must be at the highest level of security at all times. Using services or software without these tested methods in place could lead to a massive breach in security, causing problems for every person in the nation.

Who needs to be FIPS compliant?

The main organizations that are required to be FIPS 140-2 compliant are federal government organizations that either collect, store, share, transfer, or disseminate sensitive data, such as Personally Identifiable Information. All federal agencies, their contractors, and service providers must all be compliant with FIPS as well. Additionally, any systems deployed in a federal environment must also be FIPS 140-2 compliant. This includes the encryption systems utilized by Cloud Service Providers (CSPs), computer solutions, software, and other related systems. This means only those services, devices, and software that are FIPS compliant can even be considered for use by the federal government, which is one of the reasons so many technology companies want to ensure they are FIPS 140-2 compliant.

FIPS compliance is also recognized around the world as one of the best ways to ensure cryptographic modules are secure. Many organizations follow FIPS to ensure their own security is up to par with the government’s security. Many other organizations become FIPS 140-2 compliant to distribute their products and services in not only the United States, but also internationally. As FIPS is recognized around the world, any organization that possesses FIPS compliance will be seen as a trusted provider of services, products, and software. Some fields, such as manufacturing, healthcare, and financial sectors, along with local governments require FIPS 140-2 compliance as well.

About the Author

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

Table of Contents

The authenticity of those sending emails or running websites is questioned every day, as attackers will pretend to be someone they are not to compromise sensitive data of Internet users. The easiest way to prove this authenticity is through use of a digital certificate. Digital certificates utilize key pairs that only the creator of the key pair can own, thus proving they are who they say they are. The certificates are also created and signed by trusted authorities called Certificate Authorities, or CAs. CAs utilize a Chain of Trust, leading back to the original CA which is kept offline and secure, to ensure it cannot be compromised.

Certificates are not just created and given to users, however. They follow an important lifecycle which works to protect and renew certificates, so they can be continually used without fear of attackers stealing them and masking themselves as the owner of the certificate. The trust in certificates created by a certificate authority begins with the assurance that its certificate lifecycle is well managed and immune to compromise. The certificate lifecycle is extremely important to implement, as it is the equivalent of the identity of the user it is issued to.

Why is the Certificate Lifecycle important?

One of the reasons implementing the certificate lifecycle is important is due to what certificates are used for. Certificates identify websites and users on the Internet, meaning if a certificate were compromised at any point in its lifecycle, an attacker could pretend to be that person, and the user who that certificate belongs to would be blamed for any attacks associated with that certificate. Also, since the user’s key is associated with their digital certificate, that key would also be compromised, as would any data that was encrypted by that same key.

Another reason to maintain a strong certificate lifecycle is its use with websites. A compromise of a website’s digital certificate can result in outages, causing losses for the organization whose website it is. The website could also be used to infect user’s computers with malware or execute phishing campaigns, under the guise of the website owner. The first step to the proper implementation of a certificate lifecycle is knowing what each stage of the lifecycle is, and how to protect each stage.

What are the stages of the Certificate Lifecycle?

Certificate Lifecycle Stages

The stages of the certificate lifecycle are as follows:

  • Discovery
  • Creation/Purchasing
  • Installation
  • Storing
  • Monitoring
  • Renewal
  • Revocation
  • Replacement

Discovery: The discovery phase of the certificate lifecycle involves searching the network for missing, expired, compromised, or unused certificates that must be revoked, renewed, or replaced. This is an important part of the process, as it finds gaps in the security of certificates and relays these gaps to the monitoring phase, allowing for the sealing of these breaches. Normally, this phase also deals with the inventorying of certificates to help in future Discovery phases, along with any certificate audits that may occur.

Creation/Purchasing: This is the phase where the certificate is created. An online user, organization, or device requests a certificate from a Certificate Authority, which contains the public key and other enrollment information needed to enroll the user. The CA then verifies the given information and, if it is legitimate, creates the certificate. The Certificate Authority used to create the certificate can be owned by the organization that desires the certificate, or by a third-party. If the certificate is obtained from a third-party, then it must purchased from them.

Installation: The installation of the certificate is straightforward, but still just as important. The certificate must be installed in a secure, but reachable, location, as users attempting to verify the authenticity of the certificate must have access to it. When the certificate is installed, the CA puts policies in place to ensure the security and proper handling of the certificate.

Storage: As previously mentioned, when the certificate is installed, it must be in a secure location to prevent compromise. It should not, however, be so secure that the users that need to read the certificate cannot reach it. The proper policies and regulations to implement for storage of certificates will be discussed later in this document.

Monitoring: Monitoring is one of the most important stages of the certificate lifecycle. This is an almost constant phase where the certificate management systems, whether automatic or manual, watch for breaches, expirations, or compromises of digital certificates. The Monitoring stage uses the inventory created in the Discovery phase to keep track of when certificates should be revoked, renewed, or replaced. The certificate management system then moves those certificates to the next phase, which can be renewal, revocation, or replacement.

Renewal: Renewal of a certificate occurs when the expiry date of the certificate is reached. This occurs naturally with certificates, as best practice is to not use a certificate for more than 5 years at the most. Certificates can be set to renew automatically, or a list can be kept of certificate expiration dates and the administrator of the certificates can renew it at the proper time.

Revocation: If a certificate is found to be compromised, stolen, or otherwise negatively affected, then that certificate will be revoked. When a certificate is revoked, it is put on a Certificate Revocation List (CRL). This list ensures that other CAs know that this is no longer a valid certificate.

Replacement: When users switch from paying for certificates to creating their own Public Key Infrastructures (PKIs) and CAs, the certificate is replaced. This is rarely done, as it is much easier to just renew a certificate from the original provider rather than replace that certificate.


EC can help you to manage Certificates and Keys securely

Protection of each phase of the Lifecycle

Each portion of the certificate lifecycle requires its own level and methods of protection. The Discovery phase acts as a security measure in and of itself. By searching for expired or missing certificates, breaches can be detected before they become an issue. The Monitoring phase is similar, as it monitors for expired, improperly implemented, or compromised certificates. Both of these phases can be automated to allow for a better detection process. There is the potential for a manual management system missing a compromised or expired certificate.

The remaining phases require a strong level of protection and authentication. The Creation stage should ensure that the CA issuing the certificates has a valid Chain of Trust each time a new certificate is created. Installation should be correctly, as poorly implemented certificates are a breach of security that an attacker can leverage for malicious purposes. The Storage phase needs to have strong security, so that the certificates are not compromised and misused by threat actors. The revocation, renewal, and replacement of certificates must also be done securely and correctly, as these stages begin the cycle again from the beginning.

About the Author

Nishiket Kumar is a Consultant at Encryption Consulting, working with PKIs, HSMs and working as a consultant with high-profile clients.

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

Table of Contents

Digital certificates are used across the Internet to authenticate users exchanging data with one another.  Since every legitimate website uses a certificate, certificate management is extremely important. If a certificate were to be stolen and misused, an attacker could pose as another, more legitimate, source and infect a user with malware via their website. The expiration of a certificate of a certificate can result in an outage, causing an organization to lose out on potential customers. These are just a few reasons to learn more about certificate management.

What is Certificate Management?

Certificate management is the process of monitoring, processing, and executing every process in a certificate’s lifecycle. Certificate management is responsible for issuing, renewing, and deploying certificates to endpoints (servers, appliances, devices, etc.) so that network services are uninterrupted. Certificate management should also automate tasks (issuing, renewal, and so on), as well as provide real time status of the infrastructure of the network.

Certificate management helps manage the network and prevent interruptions and downtime, while providing a detailed monitoring of the whole infrastructure. Good certificate management plans should be able to handle any network, even ones with thousands of devices. If a certificate expires or is misconfigured, catastrophic outages all over the network may occur.

What is a Digital Certificate?

Any discussion of certificate management would be incomplete without explaining what a digital certificate is. A certificate, also known as an SSL/TLS certificate, is a digital identifier for users, devices, and other endpoints within a network. Certificates are linked with a public/private key pair and verify that the public key, which is matched with the valid certificate, can be trusted. The main job of a certificate is to ensure that data sent across a connection between a user and a server is kept private. The certificates does this by encrypting and decrypting data as it is sent across the connection. This is achieved through something called an SSL/TLS Handshake.

TLS Handshake

TLS Handshake Diagram

A TLS Handshake is executed as follows:

1. Client Hello:The client hello occurs when the client sends a request to the server to communicate. The TLS version, the cipher suites supported, and a string of random bytes known as the “client random” are included in the hello.

2. Server Hello: In the server hello, the server acknowledges the client hello. It then ensures it is using a TLS version that is compatible with the client TLS version, selects a compatible cipher suite from the ones offered by the client, and sends its certificate, the server random (similar to the client random), and the public key to the client.

3.Certificate Validation: The validity of the server’s certificate is first checked by the client through the certificate authority. The certificate authority, or CA, is a highly trusted entity given the responsibility of signing and generating digital certificates.

4. Pre-Master String: The client then encrypts a random string of bytes, called the “Pre-Master String” with the server’s public key and sends it back to the server. This ensures that only the server can decrypt the key with its own private key, acting as another level of security.

5. Session Key Creation: The server decrypts the pre-master key, and then both the client and server create session keys from the client random, the server random, and the premaster string.

6. Finished Messaging: The client and server then send each other messages saying they have finished creating their keys, and they compare keys with each other. If the session keys match, the TLS Handshake is completed, and the session keys are used to encrypt and decrypt any data sent between the server and client.

Once created, certificates can be used for authentication of servers, clients, or other devices. Certificates are considered valid for a certain time period, and expire after that time frame. Certificates follow a constant lifecycle which include phases such as creation, renewal, suspension, expiration, and more. If certificates are left to expire, then the certificate holder will no longer be trusted, resulting in a loss of service for the website or device being used. To receive a certificate, a user or website must first go through a certificate authority or sign one themselves.

Certificate Authorities

Certificates can be generated through either a trusted certificate authority or by signing a certificate themselves. Certificate authorities, or CAs, generate certificates for users to be used for TLS/SSL authentication. To ensure a certificate authority can be trusted, the chain of trust of the CA can be followed back to the source CA. A chain of trust is a chain of certificates published by trusted CAs, leading all the way back to the Root CA. To start the process of acquiring a digital certificate, the requestor must send out a Certificate Signing Request (CSR) to the CA. The CSR must have the public key of a key pair created by the requestor, along with information to confirm the identity of the requestor, such as a social security number or driver’s license. Once the requestors identity has been confirmed, the certificate is signed and returned by the CA and can be used for identification of the requestor.

The other option to get a certificate is to create one yourself using the same information, and then to self-sign it. This is used less often, because the identity of the signer cannot be verified with other trusted CAs, thus rendering the self-signed certificate suspicious. Due to this, many will not accept a self-signed certificate, so using a CA to create a certificate is the suggested method.


EC can help you to Combat any Outage

The Certificate Lifecycle

There are several distinct stages to the certificate lifecycle, which are shown below.

  • Discovery
  • Creation/Purchasing
  • Installation
  • Storing
  • Monitoring
  • Renewal
  • Revocation
  • Replacement

Discovery: Discovery is the first stage of the certificate lifecycle. In the discovery phase, the network is scanned for missing, expired, or unusable certificates. This phase also ensures any certificates already in place have been deployed properly. Certificates with vulnerabilities and other weaknesses can also be detected and fixed or replaced. The different certificates are commonly inventoried together in this phase to allow for tracking of certificate statuses, or grouping of related certificate types.

Creation/Purchasing: In this stage the CA creates the certificate itself, or the user purchases a certificate from a trusted CA. The key pair for the certificate is created and the public key, CSR, and personally identifiable information are sent to the CA for certificate creation. If an organization or user does not have or does not wish to create a chain of trusted CAs, a certificate is purchased instead of being created.

Installation: This stage deals with the distribution and installation of the certificate in its proper place. All aspects of the certificate’s configuration are checked in the installation phase, including the key pairs, the cipher suites, and the digital signature. The certificate is then installed onto the appropriate endpoint it was created for, and begins authentication of that endpoint.

Storing: One of the most important stages of the certificate lifecycle is the storing phase. Certificates must be accessible, but not reusable by attackers, thus they must be kept in a secure and centralized location. The storing phase can also inventory the certificates into groups, if inventorying was not done in the discovery phase.

Monitoring: This is the longest phase, where the certificates are monitored throughout the duration of their expiration period. Once the expiration date is reached, or sometimes right before, certain certificate management systems will automatically renew certificates. If automatic certificate management systems are not being used, then a system administrator will need to monitor the network’s certificates and renew, revoke, or replace any certificate that reaches its expiration date.

There are benefits to both manual and automatic monitoring, which will be discussed in-depth in the next section, but there are two important benefits which stand above the rest. The biggest benefit of manual monitoring is that if an unexpected issue occurs, then the monitor can react in real time to the problem, whereas an automatic system will not know what to do. On the other hand, an automatic monitor’s biggest benefit is that certificate renewals, revocations, etc. will not be forgotten, which can occur if a human is monitoring certificates for years.

Renewal: The renewal process of certificates begins once the validity of the certificate has run out. Once the user or automated systems decide to renew the certificate, a CSR is resent to the original issuing CA to get the certificate renewed. The process occurs as it did with originally creating the certificate, but much more quickly.

Revocation: If the issuing CA has be decommissioned, a certificate is being misused, or for a host of other reasons, then a certificate can be revoked. Once revoked, the certificate is placed on a Certificate Revocation List, or CRL, if a CRL is in use. A CRL is a list of certificates revoked by the CA that should no longer be trusted. If an Issuing CA’s certificate is on a CRL, then that CA cannot be used in a chain of trust for other CAs or certificates. A downside to using CRLs is that revoked certificates are only published periodically, not every time a certificate is revoked. This issue means a user could renew their certificate with their issuing CA, even though a few hours ago their certificate was revoked for illegitimate usage.

Replacement: If a CA’s certificate is revoked or if the certificate owner wishes to move from paid certificates to their own Public Key Infrastructure, then the replacement phase occurs. This occurs less often, as it is easier to just renew a certificate with the original issuing CA.

The certificate lifecycle is not set in stone. Different organizations will have different stages, combine stages, or leave out entire stages entirely. As long as the certificates are discovered, created, stored, monitored, and renewed, then that is considered a certificate lifecycle.

Manual vs Automated Infrastructure

One of the most important parts of a company’s data security policy is the certificate management infrastructure put into place within the organization. A manual infrastructure involves having an employee create a spreadsheet to keep track of validity periods, policies, revocations, and configuration data of all the certificates within the organization. This method will work with a smaller company with an infrastructure only dealing with a few certificates, but many larger companies can have thousands upon thousands of certificates, making manual infrastructures too complicated. The other option is to create an automated certificate lifecycle infrastructure, which is the more common method. Below is a table highlighting the differences between manual and automated certificate management infrastructures.

 

Manual Infrastructure

Automated Infrastructure

Lifecycle Stages

Handled via a spreadsheet and a user keeping track of all the certificates within the organization

Streamlined and handled automatically; Certificates renewed/replaced/revoked as soon as necessary

Operational Cost

Costs many man hours

Less cost and no man hours needed

Security

Must be constantly kept track of by the employee in charge to ensure certificates do not expire

Is constantly watched by the software set up in the infrastructure, allowing for quick renewal or replacement of certificates

Implementation

Easy and quick to implement; Only a spreadsheet is required

The software must be implemented correctly, or certificates will not be monitored correctly

These reasons, and more, are why automated certificate lifecycle management systems are used in Public Key Infrastructures.

The Importance of Certificate Management

One of the most important reasons to have a strong, automated certificate management system is if you have your own Public Key Infrastructure (PKI). A PKI is an infrastructure created to authenticate users based on digital certificates. PKIs can encrypt communications as well. The most common PKI is TLS/SSL, which uses both symmetric and asymmetric encryption in securing connections between two users. The core trust of a PKI comes from the certificates traded between the two sides of the connection. Most PKIs use a two layer architecture, which includes a Root CA and an Issuing CA.

Root CA is a certificate authority that is kept offline and creates a certificate for the online Issuing CA. This creates a chain of trust with all certificates issued by the Issuing CA, as the Root CA is kept offline so it is therefore secure from malicious intent. Issuing CAs distribute certificates for end users and devices. The less commonly used three tier architecture for a PKI includes an Intermediate CA between the Root and Issuing CA, which act as a go between for the Root and Issuing CA. The reason automated certificate management is mainly used by PKIs is because it is more secure to create a PKI correctly once and then let the automated services keep the certificates up to date. This cuts down on the cost to the company, the man hours required to keep the PKI running, and human error. Since so many organizations are creating their own PKI, proper certificate management is key to any company’s security plan.

Another reason that so much importance is put onto certificate management is the need for every device and user that is connected to the Internet to have a digital certificate. Whenever a user or a device connects to a website, the authenticity of their digital certificate is checked, along with the certificate of the website. By having a strong chain of trust and a valid certificate, you can go anywhere on the Internet.  However, a certificate is invalid or expired, if the user or device that certificate belongs to cannot go to most websites, as a secure connection cannot be established. The same holds true for website certificates. If their digital certificate is invalid, then users will not or cannot use that website, for fear of getting malware or viruses on their device.

One more reason to ensure strong certificate management is so that breaches do not occur in an organization. If a certificate were to be allowed into a network, even though it has untrusted CAs in its chain of trust, then the owner of that certificate could steal sensitive data or otherwise misuse company data for malicious purposes. Also, if the certificates are not stored properly, then an attacker could steal that certificate and pose as a legitimate user, while stealing, changing, or deleting sensitive data.


Experience Less Downtime and More Productivity

Other Certificate Uses

There are a number of other uses for digital certificates, which are listed below.

  • Intranet Portals
  • Ecommerce websites
  • VPNs
  • Point of Sales System
  • Internet of Things Devices
  • App Development
  • Code Signing
  • Email Signing
  • SSH Key Management
  • Financial Services
  • Customer Service Websites
  • Cloud Authentication

Certificate Management with Encryption Consulting

Encryption Consulting provides a variety of services relating to certificate management. We offer PKI assessments, CP/CPS development for PKIs, and PKI Design and Implementation services. Our PKI assessment will assess the current certificate management practices of our customer and help with the development of a strategy and roadmap for certificate management. Our CP/CPS development and PKI design and implementation services provide assistance in creating and implementing all the stages of a PKI, from on-premises to the cloud. We can provide our services via video or in person, at the customer’s behest. We also provide services to help develop and implement certificate management systems into new and current infrastructure.

To learn more about Encryption Consulting and the services we can provide you, visit our website: https://www.encryptionconsulting.com/.

About the Author

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download

RC4

Table of Contents

Rivest Cipher 4, or RC4, is a stream cipher created in 1987. A stream cipher is a type of cipher that operates on data a byte at a time to encrypt that data. RC4 is one of the most commonly used stream ciphers, having been used in Secure Socket Layer (SSL)/ Transport Layer Security (TLS) protocols, IEEE 802.11 wireless LAN standard, and the Wi-Fi Security Protocol WEP (Wireless Equivalent Protocol). RC4 owes its popularity, relating to stream ciphers, to its ease of use and performance speed. Now, significant flaws mean RC4 is not used nearly as often as before.

How secure is RC4?

RC4 was initially used in many applications, like SSL/TLS and WEP, until severe vulnerabilities were found in RC4 in 2003 and 2013. As RC4 was used in WEP, attackers had a chance to practice cracking it as often as they wished. With this practice, a flaw was found in RC4 where the encryption key used by RC4 could be cracked in less than a minute. RC4 keys can come in sizes of 64 or 128-bits, and the 128-bit key is able to be obtained in seconds. At the time, WEP was the only security protocol used for Wi-Fi, so the next phase, Wi-Fi Protected Access (WPA), had to be rushed for use.

Another vulnerability was discovered in RC4 in 2013 while it was being used as a workaround for a cipher block chaining issue that was discovered in 2011. Cipher block chaining is an operational mode used by block ciphers, which RC4 did not use. A group of security researchers found a way around RC4, with only a slight increase in processing power necessary in the previous RC4 attack. Due to these vulnerabilities, and other smaller ones found later, RC4 is no longer a cipher that is recommended to be used.


Is your Data Secure throughout all of the Phases of the Data Lifecycle

Variants of the RC4 cipher

There are 4 variants to the regular RC4 cipher:

  1. Spritz – Spritz is used to create cryptographic hash functions and deterministic random bit generator.
  2. RC4A – This is a variant that was proposed to be faster and stronger than the average RC4 cipher. RC4A was found to have not truly random numbers used in its cipher.
  3. VMPC – Variably Modified Permutation Composition (VMPC) is a version of RC4 that was found to have not truly random numbers used in its cipher, like RC4A.
  4. RC4A+ – RC4A+ is an advanced version of RC4A that is longer and more complex than RC4 and RC4A, but is stronger as a result of its complexity as well.

Advantages and Disadvantages

RC4 boasts a number of advantages compared to other stream ciphers:

  • RC4 is extremely simple to use, thus making the implementation simple as well.
  • RC4 is fast, due to its simplicity, which makes it a better performing cipher.
  • RC4 also works with large streams of data swiftly and easily.

Though it has advantages, RC4 has many disadvantages as well:

  • The vulnerabilities found in RC4 means RC4 is extremely insecure, so very few applications use it now.
  • RC4 cannot be used on smaller streams of data, so its usage is more niche than other stream ciphers.
  • RC4 also does not provide authentication, so a Man in the Middle attack could occur, and the RC4 cipher user would be none the wiser.

About the Author

Search any posts

A collection of Encryption related products and resources that every organization should have!

Free Downloads

Datasheet of Encryption Consulting Services

Encryption Consulting is a customer focused cybersecurity firm that provides a multitude of services in all aspects of encryption for our clients.

Download