Skip to content

Understanding Docker Image Signing

Introduction

In today’s world, all the applications or software utilized by users are virtualized and downloaded from a docker container. One fear many users have is that it might be possible that attackers tampered with the file that users are downloading from the container and have injected a malicious script or malware in it. If this is the case, whenever any person downloads and executes it in their system, the system gets affected by the attacker’s malicious script.

The Necessity for Docker Image Signing:

If an organization is providing a software/product to their customer, then how can the customer verify it is not tampered with? To provide customers with peace of mind on this subject, an organization can put their trusted signature on the software/product. If someone tries to tamper with the code, the signature gets changed. This is where image signing comes into the picture. Image signing is where an organization can sign their image before they push it to the container so that the customer can use it safely.

Similar to how malicious activity can be caught by code signing, when a user tries to install or execute the file, the signature will first be verified. If the organization’s image signing certificate is not found then it will stop the user from proceeding.

What is Docker Image Signing?

Docker image signing is the process of digitally signing docker images to confirm the software author’s identity and provide assurance that the code has not been altered or compromised.

How does Docker Image Signing work?

The way image signing works can be broken into two parts:

  1. At the server or developer side
  2. At the client side

Firstly, we’ll discuss how the
process takes place on the server side:

Server side
  1. The original image, i.e., the docker image the user wants to provide to customers safely, is firstly hashed by a hashing algorithm, because it’s practically impossible to reverse a hash.
  2. The hashed docker image we get is then signed by the private key of the developer.
  3. The signed hash docker image is then packed with the original image and digital certificate, which together are also known as an image signing certificate.
  4. Now, it can be uploaded or transferred to the customer.

Now, let’s go through how the process takes place on the client side.

Client Side
  1. The original docker image is passed through a hashing algorithm, to get the hash of the image.
  2. The public key is extracted from the certificate and applied to the signed hash of the docker image to extract the hash of the image.
  3. Both the hashes created from steps 1 and 2 are compared, and if both the hashes are the same then the image has not been changed and the signature is considered valid.
  4. At the same time, the image signing certificate is checked to ensure it was signed by a trusted CA. The expiry date of the image signing certificate is checked, and certificate is also checked against the revocation lists to ensure it is valid.

Enterprise Code-Signing Solution

Get One solution for all your software code-signing cryptographic needs with our code-signing solution.

Weaknesses of Docker Image Signing

There are several weaknesses to image signing, as well, including:
Improper management of the private key created at the beginning of the Image signing process can result in insecurity of the software being sent. If a legitimate private key is stolen, then the attacker can encode their malicious software with the private key, which will tell the user that the software is safe to use, even if it isn’t.

Threat actors can obtain a trusted certificate, but what deters most attackers is the need to provide identification information to obtain a certificate. If malicious software is distributed with a legitimate certificate, the developer can be identified and stopped.

Note: If the user allows the installation of the software, even if the Operating System says it is not a signed image, then image signing is rendered useless.

To prevent these weaknesses, there are best practices that should be followed:

For the protection of encryption keys, Hardware Security Modules, or HSMs, should be used. An HSM is a specialized, highly trusted physical device. It is a network computer that performs all the major cryptographic operations including encryptiondecryption, authentication, key management, key exchange, etc. They are tamper-resistant and use extremely secure cryptographic operations.

Along with HSMs, the principle of least privilege should be used with keys, to ensure only users who need the key have access to it.

Finally, caution should always be used with image signing. Only download and install software that is image signed by a trusted CA.

Future of Code Signing

As we can see in today’s world, security and trust are a major part of any organization to growth. Every organization wants to save its data and provide secure data to its clients. Various malicious activities are occurring daily, so image signing is going to increase exponentially. Every organization needs to put code signing and image signing into practice.

Our offering of Code Signing

Our product, CodeSign Secure, provides a secure and flexible solution to an organization’s code signing needs for signing Windows, Linux, Macintosh, Docker, and Android/iOS apps.

Our framework can be extended to protect any other code or document as requested by our customers.

  • The keys are protected by your choice of HSM, – nCipher, Utimaco, Safenet.
  • Policies and workflows are defined to secure and streamline your job submission and approval process.
  • Your existing virus and malware scans can be integrated systematically.
  • Developed on an open REST API, allowing for custom integrations and requirements.

Conclusion

Data is crucial in this connected world, where code signing can be used for the verification of data. Tampered data can lead to a severe loss and thus should not be trusted. Software should also show a warning or completely block the user from installing software with untrusted certificates. A signed software or application can achieve a trusted network of users, devices, and programs.

Comparing Data Security and Data Privacy

Often the way personal data is handled and managed is not the way it is supposed to be, especially regarding its security. There are some grave concerns about how various forms of sensitive personal data, such as financial, health, etc., are secured fundamentally. Without having the appropriate security measures and processes in place, bad actors or cybercriminals would have access to vast amounts of sensitive personal data leading to complete chaos in data management. To handle this critical and massive amount of data, we need to understand the thin line between data security and data privacy often used interchangeably.

Today, we will discuss differentiating factor between data security & data privacy and the various factors such as encryption, tokenization, & masking affecting both of them.

Data Security Vs. Data Privacy

The actual difference between data privacy and data security belongs to the fact that which data is protected and how it’s protected. Data Security is about protecting data from malicious threats and bad actors, whereas data privacy is about using data responsibly.

Data security is related to securing sensitive and critical data. Data security is primarily focused on deterring unauthorized & illegitimate access to data, via compromises, breaches or leaks, regardless of who the unauthorized party is. Enterprises use IT tools and technology such as firewalls, access control, user authentication & identification, network access control, and internal security measures to prevent such access. This also includes latest security technologies such as encryption, tokenization and masking to further enhance the data protection by making it unreadable—which, in the event of a breach, can block cybercriminals from exposing the massive amount of sensitive data.

On the other hand, data privacy is concerned with how sensitive personal data is consumed, ingested, transmitted, or processed compliantly with the data owner’s consent. Data privacy is always about informing individuals upfront that which type of data will be collected for what purpose, and with whom it will be shared under specific circumstances. Now, once the organization puts these disclaimers, the user has to agree to the terms of use, allowing the organization to use the data following the compliance standards for the stated purpose.

Data privacy is more of responsible use of data with specific disclaimers to avoid being misused and less about protecting data itself from bad actors. The use case for data privacy is somewhat different from data security; however, privacy is complemented with the data security measures such as de-identification of personal data (linking of personal data to its original subject), obfuscation and many more.

It is common to see that data security and data privacy words are used synonymously, although they are very much different in their application. Data security can be implemented on its own, whereas data privacy needs security as a pillar to stand on its own. In simple words, data privacy enables limited access, whereas data security employs various processes or methods to provide that limited access.

Tailored Encryption Services

We assess, strategize & implement encryption strategies and solutions.

Data Security and Data Privacy vs. Compliance

Now that we have understood about the data security and data privacy, we need to deep dive further to understand how the various industry regulations help organizations transform their data protection landscape.

  1. PCI DSS

    The Payment Card Industry Data Security Standard (PCI DSS) provides a framework for protecting the payment card information and cardholder data. PCI DSS is fundamentally associated with standards provided for the security controls about the storage, processing, and transmission of payment data, including the personal data such as name, address, etc., This standard applies to merchants, banks, any third parties involved, and any other entity handling cardholder data.

  2. CCPA

    The California Consumer Privacy Act (CCPA) aims for the consumer to retain ownership, power, and security of your personal information if you are a citizen of the state of California by establishing the significant rights to consumers such as:

    1. The right to know what and where personal information is being collected, sold, and disclosed about them
    2. The ability to deny the sale of personal information.
    3. The right to have equal service and price if one decides to exercise their privacy rights.
    4. The right to be able to have personal information deleted
  3. HIPAA

    The Health Insurance Portability and Accountability Act (HIPAA) provides a set of standards to protect the sensitive data of patients across the US. This regulation standard is complex as it includes a vast amount of health care data of US citizens. Companies dealing with Protected Health Information (PHI) must have administrative, physical, and technical security measures to be HIPPA compliant. There are covered entities providing treatment, accepting payments, operating in healthcare, or business associates, including anyone who has patient information and provides support in treatment, payments, or operations. General Security Rules require covered entities to maintain reasonable and appropriate administrative, technical, and physical safeguards for protecting PHI.

    1. Ensuring confidentiality, integrity, and availability of all PHI covered entities create, receive, maintain or transmit.
    2. Identify and protect against reasonably anticipated threats to the security or integrity of the information.
    3. Protect against reasonably anticipated, impermissible uses or disclosures.
    4. Ensure compliance by covered entities’ workforce.
  4. GDPR

    The General Data Protection Regulation (GDPR) is a digital data privacy standard for EU citizens. GDPR states the general guidelines for personal data, such as whose data should be protected, type of personal data, and how the data should be managed and protected. GDPR applies to all companies, which collect and process EU resident’s data. Non-EU companies would need to appoint a GDPR representative and be held liable for all fines and sanctions.

  5. NYDFS

    The New York Department of Financial Services (NYDFS) cybersecurity regulation is a set of rules applicable to the covered financial institutions. NYDFS applies to all the financial institutions operating under DFS licensure, registration, or charter or DFS regulated. The NYDFS Cybersecurity Regulation states the strict guidelines for cybersecurity rules and detailed cybersecurity plan designed by CISO, implementation of cybersecurity policy, and an ongoing maintenance and reporting system for cybersecurity incidents.

  6. HITECH

    The Health Information Technology for Economic and Clinical Health Act (HITECH) was mandated to embrace the purposeful usage of electronic health records (EHR) technology by U.S.-based healthcare providers and their business associates. HITECH means healthcare providers need to show that they are using certified EHR technology to avoid data breaches of unencrypted electronic health records.

    The HITECH Act also encouraged the stricter enforcement of the Privacy and Security Rules of HIPAA by making security audits of all healthcare providers compulsory. These audits are performed to investigate and determine whether health care providers meet minimum specified standards or not to conclude if they comply with the HIPAA’s Privacy Rule and Security Rule.

Tailored Encryption Services

We assess, strategize & implement encryption strategies and solutions.

Let’s discuss how Data Security and Data Privacy can be achieved with the help of the following security technologies:

  • Encryption
  • Tokenization
  • Masking
  • Encryption for Data Security and Data Privacy:

    Encryption provides data security for various forms of confidential data such as cardholder data, protected health information (PHI), personal identifiable information (PII), etc., by encrypting/decrypting with a mathematically derived key possessed by an authorized party. Data security becomes critical in the present environment when there are bad actors present everywhere on the internet. Many encryption applications protect personal data during data-at-rest and data-in-transit, however, leaving sensitive data unguarded in plain-text during processing.

    Although encryption became defacto standard for all data-in-transit and data-at-rest use cases, it still alone doesn’t provide the complete data privacy solution for sensitive data throughout its lifetime.

  • Tokenization for Data Security and Data Privacy:

    Tokenization plays an important and vital role while providing Data Security and Data Privacy as it has the capabilities to satisfy the requirements of both. Since the tokenization provides the functionality of pseudonymization, it can be treated as a redundant safeguarding mechanism to protect in the event of a security breach. With this technology’s help, even if the data in the organization’s system is compromised, it’s not much of use for bad actors as pseudonymization desensitizes the data by deidentifying it and making useless for cybercriminals.

    Since the data is desensitized in the organization’s system, the risk associated with data privacy is countered. So, it is clear that with the help of tokenization, our data security gets the needed strength, and on the other hand, data privacy also becomes robust because of the desensitization of personal data.

  • Masking for Data Security and Data Privacy:

    Data masking plays an instrumental role in data privacy by guarding the confidential information such as credit card information, PHI, PII etc., by replacing the actual data with the functional fictious data to be used in scenarios when the actual data is not needed. Gartner describes it as a technology that “can dynamically or statistically protect sensitive data by replacing it with fictitious data that looks realistic to prevent data loss in different use cases.” Data masking uses various mechanisms to alter the data using character or number substitution, character shuffling, or encryption algorithms. So, data masking, also known as data obfuscation or data pseudonymization, helps in handling data privacy issues for personal data to a great extent.

Conclusion

Data security and data privacy are two different approaches towards handling confidential personal data for individuals; however, often confused interchangeably. It is evident that data masking and tokenization have a deep focus on providing measures for data privacy, whereas encryption’s core focus is on data security. Considering the facts from all three security technologies, we can say that no single technology can completely secure personal information. All of them must work in conjunction to protect sensitive personal data from theft at different stages of their lifecycle.

Resources:

www.gartner.com/en/documents/3153926

A Detailed Guide to Code Signing Abuse

Introduction

Building a secure IT infrastructure involves having strong security controls in place. Some examples of this include implementing a Public Key Infrastructure, putting monitoring products in place in your environment, or utilizing legitimate Code Signing Solutions. Code Signing is the process of signing software to authenticate it for users.

Using Code Signing certificates, a software designer signs their software with a certificate containing their public key. The software recipient can then verify that the public key is a part of a key pair with the designer’s private key, thus authenticating the software. Code Signing also confirms the originality of digital information, like software code, and establishes the legitimacy of the author.

Code Signing plays an important role as it can identify legitimate software compared to malware or rogue code. In technical terms, Code Signing creates a hash of the code and encrypts it with a private key adding its signature. During execution this signature is validated and if the hash matches, it gives assurance that the code has not been modified. It also establishes assurance that the code is issued from the legitimate author that it is claiming to be.

While Code Signing provides security to code it can pose issues and can be vulnerable to attacks or abuse if not implemented properly.  The recent Solar winds attack is one such example where the code signing process was compromised and rouge code was implemented in systems and endpoints as legitimate software. An attacker’s goal is to find the path of least resistance.

There are many industries, like the gaming industry, that want to do a much faster release or deployment of their code. Such as, bypassing processes or not following securities best practices is very common, and allows organizations to fall prey to code signing abuse.

How Is Code Signing Used

Code Signing is used for a variety of purposes. The most obvious use is to sign software code with the developer’s private key. As previously mentioned, the software is signed to assure the code does not contain any malicious code, to let the recipient of the data know that the developer is who they say they are, and build trust between the developer and end-user.

With signed code, users can trust that the code holds no malicious intent in the background, as the code signer would be held responsible if this was the case. Other areas that code signing is used in is with enterprise applications, Internet of Things (IOT) devices, and Development and IT Operations (Dev Ops).

With enterprise applications, any internal code, scripts, packages, etc, are all signed via code signing. The scripts and packages are signed for the same reasons that the code is signed, as attackers could hide malicious payloads within these. IOT devices use code signing for authentication and validation purposes. Updates for both firmware and software signed by developers, as are messages between users on IOT devices.

With Public Key Infrastructures (PKIs) in use, code signing certificates authenticate users within an organization’s network. By “signing” their certificate with their private key, using the public key, the users’ identities can be validated. With Dev Ops, integration and code deployment are constantly ongoing. The code is deployed in multiple instances on containers and Cloud systems, meaning these container images must be signed during multiple stages of the code’s lifecycle.

Code Signing Abuse

A common reason for abusing code signing is to provider victims with code that looks legitimate, but contains malicious software that can steal sensitive information from users or completely destroy their systems. Attackers could also steal code signing certificates from legitimate developers, thus giving them the ability to release code under a trusted creator’s name, allowing them to release malware to more victims. Code signing abuse can occur through a number of different ways.

  • Key Theft

    When digital certificates or keys are poorly stored and managed, it opens the door to threat actors, letting them steal the private keys of trusted users. Using these keys, they can sign code as another identity, and they can have certificates issued in the trusted identities name and misuse that certificate within the network.

    For instance, a small software development company stores its private key on an unsecured server. An attacker can steal the key by gaining access to the server using a phishing attack targeting the admin. Through the use of Hardware Security Modules (HSMs) keys can be kept completely secure from attackers, as they would need to physically access the HSM with the proper credentials to steal the keys stored inside.

  • Coding Errors

    Another, less thought of, error that code signing can be abused is if code signed software contains vulnerabilities. If vulnerabilities are present in software, and threat actors discover them before they are patched, then their code signing was for naught. Even though the code is signed, these vulnerabilities can be leveraged by attackers to deploy malware onto victim’s systems. Code should be thoroughly tested before deployment, to ensure that no vulnerabilities are present.

    For example, a developer rushes a software upgrade to fix a high-priority bug. The code is signed and pushed out to customers without proper security testing. However, this code contains backdoor gateways to access sensitive customer information, which can lead to many consequences for the organization and its clients.

  • System Compromise

    If a system is compromised, and software is being signed on that system, the code can be changed before the actual signing. This allows malware payloads to be hidden in code that is legitimately signed, without the developer’s knowledge. Once inside the system, the attackers can inject a small piece of malicious code into the software before the build is signed. Code signing was abused in this way in the recent SolarWinds attack. Ensuring your systems are up to date with all security patches can ensure the security of your online environment.

  • Use of Revoked/Expired Certificates

    When a key or expired certificate is compromised, if the validity of that certificate is not checked by a Certificate Authority (CA), then that certificate can be used to allow for code signing of malicious software.

    Certificates that have expired or been revoked should be put in the Certificate Revocation List (CRL) so that CAs can note that that certificate should no longer be used for anything until its replacement or renewal.

Enterprise Code-Signing Solution

Get One solution for all your software code-signing cryptographic needs with our code-signing solution.

Well-Known Code Signing Abuses

By learning from past code signing abuses, we can safeguard data in the future. A number of notable code signing abuses have occurred in the past, but today we will focus on three of the higher profile ones, starting with SolarWinds. In 2020, the organization SolarWinds found that its core systems had been compromised. Utilizing a supply chain attack, attackers managed to gain access to a Microsoft365 account owned by SolarWinds in September 2019.

This allowed the threat actors to gain access to SolarWinds code and other systems, and giving them the ability to implement code signing abuse. By editing code before it was signed, these attackers were able to implement a type of malware called a Remote Access Trojan, or RAT, that gave them remote access to victim’s computers.

This RAT was hidden inside the updates of a network monitoring software created by SolarWinds called Orion. This started a campaign that created a command-and-control infrastructure on the victim’s devices. Government officials, private organizations, and many US federal government agencies were affected by Solar Winds.

Another attack that utilized code signing abuse was the D-Link attack. A network equipment provider called D-Link accidentally published their private code signing keys when publishing their source code for a firmware update. In this case, attackers could utilize these keys to side code of their own making, but have recipients believe that they are receiving trusted code from D-Link.

The importance of protecting private code signing keys cannot be overstated, as having your digital identity stolen can lead to sensitive data loss, lawsuits, and more. With the D-Link attack, only one of the four signing keys leaked was valid, but all it takes is one valid certificate for it to be misused.

One last code signing abuse we will talk about is Shadow Hammer. In 2019, a big-name computer manufacturer called ASUS had their code signing process compromised. Using ASUS’ software’s live update utility, the threat actors released malware to create backdoors into thousands of users’ computer systems.

Because the malware was signed by ASUS, the live update tool updated the systems, allowing the attackers to steal sensitive data from the victims. Again, protecting systems by updating software and keeping your other systems secure will stop your code signing process from being taken over.

Safeguarding Code Signing Certificates

There are a number of different code signing best practices that can be followed to ensure your code signing process has a secure environment to work in. The National Institute of Science and Technology (NIST) releases a number of recommendations on certificate and code signing best practices for users to view. Some are more obvious than others, but we will go through all types of them anyways.

  1. Securing private keys on HSMs

    One of the weaknesses of many organizations is the lack of security surrounding their private keys. Whether on the Cloud or on-premises, Hardware Security Modules can fully protect your private keys from attackers. A Hardware Security Module is a specialized, highly trusted physical device which performs all major cryptographic operations, including encryption, decryption, authentication, key management, and key exchange.

    HSMs are specialized security devices, with the sole objective of hiding and protecting cryptographic materials. They have a robust OS and restricted network access protected via a firewall. HSMs are also tamper-resistant and tamper-evident devices. As an on-premises HSM must be physically accessed to steal keys, they are considered one of the best possible ways to stop unwanted users from accessing private cryptographic keys.

  2. Control of the Code Signing Process

    Just from two of our three real life examples of code signing abuse, you can see that controlling your organization’s code signing process is vital for following code signing best practices. Part of securing the code signing process is using authentic and secure code signing solutions, if you decide to go this route.

    Code signing solutions provide all the infrastructure for signing code and other documents, while you deal with the security of system. Along with secure code signing solutions, controlling who can access private keys, validation of user’s identities, and use of two-factor authentication on code signing services are just a few other ways to manage your code signing process.

  3. Code Validation

    Before signing any code, applications should be thoroughly checked for vulnerabilities or malware. Along with this, deprecated function calls should be removed from code. Double and triple checking code for vulnerabilities or security gaps can save your organization from releasing insecure code that can be leveraged by threat actors to steal sensitive data from your users.

  4. Code Signing Devoted Systems

    To ensure the highest level of security with the code signing process, the system implementing code signing should ONLY do code signing. In this way, there is no vulnerability caused by another type of software that can affect your code signing services. Two of the previously mentioned cases of code signing had their code signing process hijacked due to vulnerabilities in other software.

    If a computer has many different software downloaded on their computer, each one is a potential vector for attackers to misuse. Also, part of this practice is the idea that the system should be fully updated and patched, to allow for the most secure environment possible.

  5. Certificate Validity Checking

    When running a PKI, certificates must be validated before they are allowed to be used. With code signing, the case is the same. No certificate should be used for code signing, unless its validity has been verified. Certificates should be checked for their validity not only before code signing, but as a part of the process as well. This protects from any oversight in the Public Key Infrastructure that may occur.

  6. Certificate Lifecycle Management

    A key component of running a successful PKI is having a strong Certificate lifecycle management plan in place. The steps of the Certificate Lifecycle, and how to secure certificates in each phase, are as follows:

    1. Discovery

      With the discovery phase of the certificate lifecycle, the network is searched for missing, expired, compromised, or unused certificates. If found, these certificates must be revoked, renewed, or replaced. This phase of the lifecycle is extremely important, since it finds gaps in the Public Key Infrastructures’ security and relays these gaps to any monitoring tools in place. This allows the breaches in the system to be patched without any sensitive data loss.

      This management phase also inventories the certificates within the PKI, to help in future Discovery phases and any PKI audits that may occur. Discovering of mismanaged or expired certificates should be done with only trusted software, as missing a certificate in the Discovery phase can lead to attackers being able to use that certificate for code signing abuse.

    2. Creation/Purchasing

      In the Creation/Purchasing phase of the lifecycle, the certificates are created or purchased for use by the certificate requestor. A user or device sends a Certificate Signing Request (CSR) to an Issuing Certificate Authority. The CSR contains the public key and other enrollment information needed to enroll the user within the PKI. The CA then verifies the information contained within the CSR and, if the information is valid, creates the certificate for the user.

      The Issuing Certificate Authority can be a part of the organization’s own PKI or a member of a third-party Public Key Infrastructure. If a third-party PKI is used, then the certificate must be purchased. When creating or purchasing certificates, the Issuing CA should be certain that the data contained in the request is legitimate, as an attacker may be posing as another person to gain a certificate for malicious use.

    3. Installation

      The installation of a certificate is extremely important to get right, as a poorly installed certificate can be misused for malicious activity. Access to the certificate should be possible, as browsers and other users must be able to verify the authenticity of the certificate.

      Even so, security of the certificate is still of the utmost importance in the Installation process. To ensure the strongest level of certificate handling and security, when the certificate is installed, the CA puts policies in place which ensure only authorized individuals can make changes to the certificate.

    4. Storage

      To prevent compromise, storage of code signing certificates is vital, as poorly stored certificates can be taken and used by threat actors. As previously mentioned, though it should be securely stored, certificates still need to be readable by software and other users to authenticate the certificates. To provide strong storage, utilize Hardware Security Modules to store certificate private keys.

    5. Monitoring

      Keeping track of certificates and their status is vital for a strong code signing process. This is a phase that is constantly occurring, as certificates can expire or become lost at any time. The Monitoring stage keeps track of certificates that must be revoked, renewed, or replaced, via the inventory initially created in the Discovery Phase.

      If a certificate is found to be in need of replacement, renewal, or revocation, that certificate is moved on to the next portion of the Certificate Lifecycle. Strong, automated monitoring systems should be in place for proper monitoring. Automated monitoring ensures that human oversight will not occur, and certificates in need of the next phase are not overlooked.

    6. Renewal

      A certificate enters the Renewal stage of the certificate lifecycle when it nears its expiration date. Certificates should have an expiration date of more than 5 years at the most to follow best practices.

      Depending on if automated or manual certificate renewal is in place, certificates can be set to renew automatically as their expiration date nears, or a system administrator can keep a list of all the certificates’ expiration dates so that they can be manually renewed at the proper time. It is best practice to automate the renewal process, as human error can cause oversight of certificate expiration dates.

    7. Revocation

      Certificates must be revoked if they have been found to be improperly used, or otherwise misused. When a certificate is revoked, that certificate as well as its data is entered into a Certificate Revocation List.

      This list is regularly checked by Certificate Authorities so that any Certificate Signing Requests containing that same data are rejected. To protect the revocation phase of the Certificate Lifecycle, CRLs should be kept up-to-date, as allowing the use of revoked certificates to occur will give threat actors access to sensitive data.

    8. Replacement

      The final phase of the Certificate Lifecycle is the Replacement phase. When moving from purchasing certificates to creating your organizations own, the purchased certificates must be replaced. This is rarely done, as it is much easier to just renew a certificate from the original provider rather than replace that certificate.

      Replacement of certificates should be done only by trusted Issuing Certificate Authorities. Along with this, best practices should be followed in each phase of the Lifecycle following the Replacement phase, as the Certificate Lifecycle restarts when a certificate is replaced with a new one.

Enterprise Code-Signing Solution

Get One solution for all your software code-signing cryptographic needs with our code-signing solution.

Encryption Consulting’s Code Signing Services

To protect your Code Signing Process at every phase, take a look at Encryption Consulting’s Code Signing Solution – CodeSign Secure. CodeSign Secure provides a secure and flexible solution to your code signing needs for all Operating Systems including Windows, Linux, Macintosh, Docker, and Android and iOS applications. Digitally signed code ensures that the software running on computers and devices is trusted and unmodified.

We protect your code signing keys with your choice of HSM that is FIPS 140-2 Level 3 compliant. We help you design workflows and policies to secure and streamline your job submission and approval process. Along with this, we will fully integrate your malware and virus detection software with CodeSign Secure to give you the best possible monitoring of the code signing process. CodeSign Secure was developed on an open REST API, allowing for custom integrations and requirements.

Protecting Data from IP Spoofing

Spoofing is an impersonation of a user, device, or client on the Internet. It is often used during a cyberattack to disguise the source of attack traffic.

The most common forms of spoofing are:

  1. DNS server spoofing

    Modifies a DNS server to redirect a domain name to a different IP address. It is typically used to spread viruses.

  2. ARP spoofing

    Links a perpetrator’s MAC address to a legitimate IP address through spoofed ARP messages. It is typically used in denial of service (DoS) and man-in-the-middle assaults.

  3. IP address spoofing

    Disguises an attacker’s origin IP. It is typically used in DoS assaults.

What is IP spoofing?

IP spoofing is the creation of Internet Protocol (IP) packets which have a modified source address to either hide the identity of the sender, to impersonate another computer system, or both. It is a technique often used by bad actors to invoke DDoS attacks against a target device or infrastructure surrounding that device.

Sending and receiving IP packets is a primary way in which networked computers and other devices communicate and constitutes the basis of the modern Internet. All IP packets contain a header which precedes the body of the packet and contains important routing information, including the source address. In a normal packet, the source IP address is the address of the sender of the packet, If the packet has been spoofed, the source address will be forged.

IP Spoofing is analogous to an attacker sending a package to someone with the wrong return address listed. If the person receiving the package wants to stop the sender from sending packages, blocking all packages from the bogus address will do little good, as the return address is easily changed. Similarly, if the receiver wants to respond to the return address, their response package will go somewhere other than to the real sender. The ability to spoof the addresses of packets is a core vulnerability exploited by many DDoS attacks.

How does IP spoofing work?

To start, a bit of background on the Internet is in order. The data transmitted over the Internet is first broken into multiple packets, and those packets are transmitted independently and reassembled at the other end. Each packet has an IP (Internet Protocol) header that contains information about the packet, including the source IP address and the destination IP address.
In IP spoofing, a hacker uses tools to modify the source address in the packet header to make the receiving computer system think the packet is from a trusted source, such as another computer on a legitimate network, and accept it. Because this occurs at the network level, there are no external signs of tampering.
IP spoofing facilitates anonymity by concealing source identities. This can be advantageous for cybercriminals for these three reasons.

  1. Spoofed IP addresses enable attackers to hide their identities from law enforcement and victims.
  2. The computers and networks targeted are not always aware that they’ve been compromised, so they don’t send out alerts.
  3. Because spoofed IP addresses look like they are from trusted sources, they’re able to bypass firewalls and other security checks that might otherwise blacklist them as a malicious source.

Tailored Encryption Services

We assess, strategize & implement encryption strategies and solutions.

What are the different types of IP spoofing attacks?

IP spoofing attacks can take several forms. It depends on the vulnerabilities of victims and the goals of the attackers. Here are a few common malicious uses for IP spoofing:

  1. Masking botnet devices

    IP spoofing can be used to gain access to computers by masking botnets, which are a group of connected computers that perform repetitive tasks to keep websites functioning. IP spoof attacks mask these botnets and use their interconnection for malicious purposes. That includes flooding targeted websites, servers, and networks with data and crashing them, along with sending spam and various forms of malware.

  2. DDoS attacks

    IP spoofing is commonly used to launch a distributed denial-of-service (DDoS) attack. A DDoS attack is a brute force attempt to slow down or crash a server. Hackers can use spoofed IP addresses to overwhelm their targets with packets of data. This enables attackers to slow down or crash a website or computer network with a flood of Internet traffic, while masking their identity.

  3. Man-in-the-middle attacks

    IP spoofing is also commonly used in man-in-the-middle attacks, which work by interrupting communications between two computers. In this case, IP spoofing changes the packets and then sends them to the recipient computer without the original sender or receiver knowing they have been altered. An attacker becomes the so-called “man in the middle,” intercepting sensitive communications that they can use to commit crimes like identity theft and other frauds.

How to protect against IP spoofing

Here are steps you can take to help protect your devices, data, network, and connections from IP spoofing:

Use secure encryption protocols

to secure traffic to and from your server. Part of this is making sure “HTTPS” and the padlock symbol are always in the URL bar of websites you visit.

Be careful of phishing emails

from attackers asking you to update your password or any other login credentials or payment card data, along with taking actions like making donations. Phishing emails have been a profitable tool for cybercriminals during the coronavirus pandemic. Some of these spoofing emails promise the latest COVID-19 information, while others ask for donations. While some of the emails may look like they are from reputable organizations, they have been sent by scammers. Instead of clicking on the link provided in those phishing emails, manually type the website address into your browser to check if it is legitimate.

Take steps that will help make browsing the web safer

That includes not surfing the web on unsecure, public Wi-Fi. If you must visit public hotspots, use a virtual private network, or VPN, that encrypts your Internet connection to protect the private data you send and receive.

Security software solutions

that include a VPN can help. Antivirus software will scan incoming traffic to help ensure malware is not trying to get in. It is important to keep your software up to date. Updating your software ensures it has the latest encryption, authentication, and security patches.

Set up a firewall to help protect

your network by filtering traffic with spoofed IP addresses, verifying that traffic, and blocking access by unauthorized outsiders. This will help authenticate IP addresses.

Secure your home Wi-Fi network.

This involves updating the default usernames and passwords on your home router and all connected devices with strong, unique passwords that are a combination of 12 uppercase and lowercase letters, at least one symbol and at least one number. Another approach is using long passphrases that you can remember but would be hard for others to guess.

Monitor your network

for suspicious activity.

Use packet filtering systems

like ingress filtering, which is a computer networking technique that helps to ensure the incoming packets are from trusted sources, not hackers. This is done by looking at packets’ source headers. In a similar way, egress filtering can be used to monitor and restrict outbound traffic, or packets that don’t have legitimate source headers and fail to meet security policies.

Real uses for IP spoofing

IP spoofing also may be used by companies in non-malicious ways. For example, companies may use IP spoofing when performing website tests to make sure they work when they go live.
In this case, thousands of virtual users might be created to test a website. This non-malicious use helps gauge a website’s effectiveness and ability to manage numerous logins without being overwhelmed.

Resources:

www.us.norton.com/internetsecurity-malware-ip-spoofing-what-is-it-and-how-does-it-work.html
www.cloudflare.com/learning/ddos/glossary/ip-spoofing/

Digital Certificates – Certificate Chaining

Introduction

Public Key Infrastructure (PKI) is one-way organizations that ensure authenticity of people, devices, and more. In a well-established PKI, certificates play a significant role in authorizing and authenticating users’ identities. Since certificates are generated, revoked, and updated regularly to keep the infrastructure functional, we need to understand how the certificates are generated, how they are used to authenticate, and how certificates are linked.A key pair is also made when a certificate is created, composed of both a private and public key, which can be used for asymmetric encryption, digital signing, and more.

The private key is often secured inside an HSM to avoid data leakage, which can lead to key compromise. Each certificate contains the certificate holder’s public key, which would give the certificate the authenticity of that public key. While establishing a secure connection, the attached public key can be used for asymmetric encryption, and the user would not need to worry about any Man in the Middle (MITM) attacks.Now, we will break it down and start from the first certificate generated in the network to understand each concept.

Root CA certificate

The Root CA is the backbone of a PKI and is thus kept offline. The Root CA self-signs its certificate and establishes the Root of trust between identities to issue a digital certificate. The Root CA signs a certificate for the Issuing CA and other Intermediate CAs, such as Policy CAs, in the case of a three-tier architecture. The Root certificate is similar to any other certificate you may come across, but the Root certificate generally does not contain a CDP or an AIA.

Since no one can revoke a Root certificate, if the Root CA is compromised the whole PKI would need to be changed. If the Root CA is a public CA, its certificate can be added to Certificate Trusted Lists (CTLs) found in the Certificate Manager tool (certmgr.msc), and thus the root certificate will be trusted.

Intermediate CA or Issuing CA

The Root CA signs a certificate for Issuing CAs and gives them the ability to create end-entity certificates assigned to an identity of a user, device, or program. Issuing CA certificates are signed using the Root CA’s private key. The certificate also contains Authority Info Access (AIA), which shows certificate viewers the URL of the Root certificate, which is the issuer of the Issuing CA’s certificate.

The Issuing CA’s certificate also contains the CRL Distribution Points (CDP), which can confirm whether or not the certificate has been revoked.

The Issuing CA certificate is used to generate end-entity certificates, and the certificate’s private key is used to sign those end-entity certificates.

End Entity Certificates

End Entity certificates are issued by the Issuing CA, which uses its private key to sign the certificate. End entity certificate can be a server certificate or a device certificate such as a firewall. End entity certificates can be used for security services such as authentication, data confidentiality, and data integrity.

Each certificate contains a public key that can be used as a digital signature to encrypt data, establish encrypted sessions, etc.

Enterprise PKI Services

Get complete end-to-end consultation support for all your PKI requirements!

Certificate Chaining

A certificate chain is a hierarchy of certificates that starts from end entity certificates. It is traced back to the issuer, which finally leads up to the Root CA’s self-signed certificate.

Certificate chains are used to verify the public key’s authority and other information in a typical TLS/SSL certificate, including if the certificate belongs to the subject mentioned. To verify this, the signature of the certificate is verified with the public key contained in the issuer’s certificate, whose signature is further verified by its issuer’s public key. This is continued until we reach the Root certificate, the last certificate in the chain. To verify certificate chaining, the following steps are taken:

  1. The issuer of each certificate should match with the subject of the following certificate. So, the end entity’s certificate’s issuer should correspond with the subject of the Issuing CA’s certificate, and so on. This should continue until we get to the Root certificate, which would be self-signed. This Root certificate’s issuer and the subject would be the same. If we successfully verify all certificates from end-entity to Root, it confirms that the certificates are properly chained.
  2. When a certificate is issued, the private key of that CA is used to sign the certificate, and its respective public key would be attached to the Issuing CA’s certificate. Thus, the issued certificate signature should be verified by the public key in the issuer’s certificate.
  3. The root certificate is the trust anchor of the PKI. The root certificate should be stored in Microsoft Certificate manager, letting browsers trust certificates having the Root certificate as the last certificate in their certification path.

Thus, for a certificate to be trusted, the certificate should have a valid issuer and should trail back to a trusted root CA. Therefore, all Intermediate CAs and end-entity certificates would become trusted.

Verifying Certificates

When a browser downloads an end-entity certificate, it is also downloading the issuer’s certificate or a bundle of certificates. When the verification of the certificate starts, firstly, the certificate chain is built. If it was successful and the root certificate is verified, the certificate’s validation period is checked. If the certificates are valid and the certification chain was also successfully built, the certificate can be trusted. If any of the validations were missed, the browser would warn or stop the user from visiting the website.

Conclusion

Certificates are crucial in this connected world, where certificates can be used for authentication, encryption of communication and data, and for ensuring data privacy. Incorrectly configured PKIs can lead to bad certificates and thus should not be trusted. Browsers will also show a warning or completely block the user from visiting a website with untrusted certificates. A healthy Public Key Infrastructure should create certificates that can create certificate chains and verify signatures, thus achieving a trusted network of users, devices, and programs.

A Detailed Guide on Building your own PKI

Introduction

With the ever-changing and expanding enterprise infrastructure, it has become extremely important that every organization have their own robust and mature Public Key Infrastructure (PKI) set up that can establish trust between their systems, applications, users, and devices on untrusted networks. The adoption of private cloud, public cloud, DevOps, microservices, and the addition of IOT and network connected devices presents a wide range of areas to protect. A Public Key Infrastructure not only provides trusted identities to users and devices, but also provides a secure channel to protect communications in-transit.

Today, most PKI setups in organizations are decades old and need to be revamped and upgraded to match the changing IT landscape. The biggest need for most organizations is to provide a highly secure and very robust PKI setup that can issue and manage digital certificates quickly through self-provisioned systems. An internal PKI setup by the organization should also support both on-premises and Cloud systems, to meet DevOps requirements. But how does a PKI work?

What is a PKI and how does a PKI work?

A PKI is a setup that provides digital certificates to end-users, systems, devices, and applications to provide them with trusted identities. These identities are used for authentication of the certificate holder, as well as for establishing secure communications to other certificate holders within the network. A PKI infrastructure is based upon asymmetric key cryptography utilizing a public key and private key pair associated with a digital certificate issued by an Issuing Certificate Authority (CA). This certificate authority establishes trust between two certificate holders with the help of these digital certificates. Along with providing the certificate holders with their identity, these certificates also provide access rights and enables the certificate holder to establish a secure channel between two certificate holders to communicate.

Components of PKI

  1. Root CA: The Root CA is the most important component of a PKI infrastructure. The Root CA issues certificates and establishes the root of trust between identities to which it issues a digital certificate. The Root CA also issues certificates to Issuing CAs, giving them the power to issue certificates for the Rot CA, as it is normally kept offline.
  2. Intermediate CA: An Intermediate CA, also known as a Subordinate CA, is a Certificate Authority that is set between the Issuing CA, which issues certificates on behalf of the root CA. Root CAs can have a lot of Intermediate CAs underneath them in the PKI hierarchy, but each Intermediate CA can only have one Root CA. The Intermediate CA is normally only used in a three-tier PKI architecture.
  3. Issuing CA: The Issuing CA issues certificates to end-users, devices, and other certificate requestors. Issuing CAs act like online Root CAs, issuing certificates to users who need them. Issuing CAs are used in both two-tier and three-tier CAs.
  4. Public Key: A cryptographic key which is created by an asymmetric key algorithm, such as RSA, and that can be issued to the public along with a digital certificate. A public key is not required to be stored securely and is used for public distribution. The public key is one half of the asymmetric key pair created with an asymmetric key algorithm.
  5. Private Key: A cryptographic key which is the other half of an asymmetric key pair. The private key is the most important component of authentication and should be stored securely.
  6. Certificate Store: A certificate store is used to store root certificates issued from multiple CAs. Certificate stores also contains Intermediate CA root certificates and end user certificates. The certificate store tells a computer which CAs are trusted CAs.
  7. Certificate Revocation List (CRL): A CRL is a list that that contains information on revoked certificates, including their certificate information and the reason for the certificate’s revocation. CRLs are published at certain time intervals, potentially causing issues with certificates revoked between CRL publication times.
  8. Delta CRLs: Delta CRLs are CRLs published in the time interval between CRLs being published. This covers the potential for overlooking a certificate revoked before the publishing of the next CRL.
  9. HSM (Hardware Security Module): An HSM is a very important component of a secure PKI setup and is advised to be used to store the Root CA’s private key. HSMs can also be used to store the private keys of Intermediate Certificate Authorities. HSMs are extremely secure, with tamper-resistant and tamper-evident safety mechanisms.
  10. Certificate Management: Certificate Management is an important aspect of a PKI infrastructure, as it helps with keeping certificates up-to-date and secure. The following are different phases of the Certificate Lifecycle that are used for Certificate Management.
    1. Certificate Enrollment: This phase relates to the initial creation of a certificate for the certificate requestor. An online user, organization, or device sends out a Certificate Signing Request, or CSR, to the Certificate Authority. The CSR contains the public key of the requestor and other information relating to the requestor. The CA then verifies the given information and, if it is legitimate, creates the certificate and enrolls the user in the PKI. 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 be purchased from them.
    2. Certificate Issuance: Once the certificate has been created, and the user has been enrolled in the PKI, the certificate is issued to the user. As previously mentioned, the user now uses this certificate to identify themselves within the network. This ensures that each member of the PKI trusts the certificate holder.
    3. Certificate Validity: Certificate validity involves the checking of the validity of the certificate when interacting with another member of the network. The way this certificate is verified is by following the chain of trust of the certificate. This chain of trust, or certification path, shows the certificate of the Issuing CA that issued the certificate being verified. The certification path of the Issuing CA’s certificate is then checked, going all the way up until the Root CA’s certificate is reached. Once the chain of trust is verified up to the Root CA, that certificate originally being verified is now seen as valid.
    4. Certificate Revocation: This step only occurs if the certificate expires and is no longer needed, if the certificate is stolen and misused, or if the certificate in general is no longer needed. If any of these situations occur, then the certificate is revoked and can no longer be used. The revoked certificate is then added to the CRL.
    5. Certificate Renewal: When a certificate expires, it must be renewed. This process reissues the certificate, using the same key pair and information, but with a newly updated expiration date.
  11. Certificate Policy (CP): The Certificate Policy is a document setting forth standards of the PKI. The CP lets users and PKI maintainers know how to apply for a certificate, the naming standards for certificates, and more. The CPS follows the standards set forth in the CP.
  12. Certificate Practice Statement (CPS): The Certificate Practice Statement sets forth the procedures used in the PKI. These procedures are based around the Certificate Policy’s standards. The CP tells a user or maintainer what to do, while the CPS tells them how to do it.

Enterprise PKI Services

Get complete end-to-end consultation support for all your PKI requirements!

Certificate Details

A digital certificate contains the following information to prove the identity of the certificate holder:

  • Details of Certificate Issuer: The Issuer details include the name of the Issuing CA, shown on the General tab under the “Issued by” field and in the Details tab under the “Issuer” field. The “Issuer” field not only shows the name of the Issuing CA, but also the Common Name, Organization name, and Country of the the Issuer.

    Issuing CA
  • Details of the Certificate holder: The Certificate holder details in the certificate include the holder’s public key, their public key, and the name of the certificate holder.

    PKI Certificate holder details
  • Certification Path: Also included in a digital certificate is the certification path of the certificate. This helps other users, applications, or devices within the network verify the validity of the certificate.

    digital certificate path
  • Public key: As mentioned, the certificate holders public key is stored within the certificate. This, along with their own private key, verifies that the key holder matches the public key within the certificate.

    public key certificate holders
  • Key usage & extended key usage: The “Key Usage” field tells the viewer what the key is used for. There is also a chance that the certificate has an “Extended Key Usage” field, which tells of other uses for the key, that is not included in the “Key Usage” field.

    Extended Key Usage
  • Digital signature of the issuer: One other important part of a digital certificate is the issuer’s digital signature. This helps with verification of the certificate, as it lets the viewer know who issued the certificate.

    PKI verification of the certificate
  • Common Use Cases of Digital Certificates

    The “Key Usage” field can offer a lot of different uses for the digital certificate. The following are some of the most common usages for certificates:

    • SSL/TLS certificates to secure communication channels – One of the main certificate uses is for SSL/TLS communication. This involves keeping communications secure between a client and server or a client and another client.
    • Digital signatures for documents – Certificates can also be used as digital signatures for documents. Digitally signing a document lets the recipient of the document know that the signer has sent the document and that there is nothing malicious within the document.
    • Code signing – Code signing with certificates is very similar to document signing. When code is created, the code designer signs the code to verify they have created it and that no malicious code is hidden within.
    • Client-server authentication – Client-server authentication verifies the identity of both the client and server to the other party of the communication. The respective communicators check the certification path of the other’s certificate, verifying that their certificate is valid.
    • VPN authentication – Similarly to client-server authentication, VPN authentication verifies the identity of each member of the connection using their certificate’s certification path.
    • Email & data encryption – Email and data encryption uses the sender’s private key to encrypt data. Once the email is received, since the certificate is public knowledge and contains the sender’s public key, the message can be decrypted and the recipient will know that the sender is who they say they are.
    • Wifi authentication – Wifi authentication also verifies the identity of each member of the connection using their certificate’s certification path.

    Enterprise PKI Services

    Get complete end-to-end consultation support for all your PKI requirements!

    Key elements to setup your own PKI

    • Identify your certificate requirements – You must first identify all current and future requirements for digital certificates. This refers to what your certificates within your PKI are, and will, be used for. See the Common Use Cases for Digital Certificates section above for more information.
    • Selecting the Right Certificate Authority – Based upon your requirements, you must select the type of Certificate Authority you want to setup. If you are typically using your PKI to support your enterprise requirements, which are mostly based on Microsoft services, then setting up a Microsoft CA would be a good option for your organization. Other types of CAs are Google and Amazon CAs.
    • Cloud vs On-premises hosting – Traditionally, all internal PKIs aare setup on-premises. More and more often, however, applications and services are migrating to the Cloud, so it is important to support Cloud requirements. In situations where the majority of services and products are on the Cloud, it is important to ensure that the CA you are setting up supports Cloud-based requirements.
    • Certificate Management – Just setting up an internal PKI infrastructure does not ensure that your organization will be able to meet and manage all PKI-related requirements. One of the most important requirements of a PKI infrastructure is automating certificate management operations. More so with DevOps, continuation, and CI/CD pipeline, it is also very important to make provisioning and deprovisioning certificates zero touch and instant. This ensures all certificate operations necessary are quick to be completed and human error will not effect them.
    • Securing your Root & Issuing CA private keys – The private keys of the Root and Issuing CA’s have to be stored with the utmost security because they form the root of trust. As such, it is important that these private keys are stored securely on an HSM. Typically the Root & Issuing CA private keys are stored on the HSM, which provides maximum security and stops any tampering or misuse with these keys.
    • Creating CP (Certificate Policy) & CPS (Certificate Policy Statement) creation – The CP & CPS of the PKI define the policies for your Certificate Authorities and will help you design your PKI infrastructure. These documents also act as the framework and scope of your Certificate Authority, telling it to whom it can issue certificates, what the boundaries within which the CA will work are, and the procedures used to manage your CA.
    • Certificate revocation and CRL checking – One more important step in creating your PKI is ensuring that certificates are revoked when necessary, and that when they are revoked, they are placed into the CRL. It is also important to have your CAs regularly check for new CRLs, allowing them to be up-to-date on the latest revoked certificates.

    Basic Architectures

    The two most common PKI architectures are the two-tier and three-tier architecture. Below are the PKI components that make up each type of PKI architecture:

    Two-Tier Architecture

    A two-tier architecture is the most common form of PKI hierarchy, and also the most balanced architecture. It involves only a Root CA and the Issuing CAs in the PKI. This format makes it simple to deploy a two-tier PKI, without losing the security of the PKI. The below image shows how the setup of a two-tier PKI looks.

    two tier pki


    The design of a two-tier PKI architecture works with security and simplicity in mind, allowing the root of trust, the Root CA, to stay offline, protecting it from attack. Since the Root CA cannot be compromised, there is no worry that certificates are being misused or given to untrusted users. Instead of the Root CA giving out certificates, it creates the certificates for its original Issuing CAs, and allows them to to issue certificates to end-users. Two-tier PKI architectures are the most common type of hierarchy used.

    Three-Tier architecture

    3 Tier PKI infrastructure

    The three-tier architecture is the most secure, as there are more links in the chain that would need to be compromised by attackers. However, setting up a three-tier architecture is a much more complicated process than setting up a two-tier architecture. With Intermediate CAs added into the mix, there are many more CAs to set up and integrate within the PKI, especially if a large number of Issuing and Intermediate CAs need to be created. The more CAs needed in a PKI, the more complicated implementation and maintainence is. A three-tier architecture is used much less often than a two-tier architecture.

    Common Deployment Mistakes

    • Lack of planning and tracking: One of the more common mistakes with a PKI is the lack of planning and tracking. Poor planning in a PKI can hurt a PKI critically, as there may be security gaps that an attacker could exploit. Poor planning can also lead to poor certificate and key management, offering another avenue for attackers to exploit. Along with planning, poorly tracking PKI assets can also cause issues. To fix these issues, ensure proper planning is completed by PKI professionals, to ensure the best quality PKI. Utilizing SIEM tools can also help track the different components of your PKI, giving you more transparency into it’s inner workings.
    • Root CA Security: As the root of trust, the Root CA is vitally important to the PKI, and thus must be well secured. If the Root CA were to be compromised, the entire PKI would need to be recreated from scratch, as no certificates issued within that PKI would be trusted any more. To fix this, utilize an HSM to keep the Root CA’s keys secure from outside attack.
    • Bad Certificate Lifecycle management: Another common PKI deployment mistake is poor certificate lifecycle management. If certificates are compromised or left unused, malicious users could use the certificates to steal or access sensitive data. Also, if a user or application’s certificate were to expire without renewal, a loss of service could occur for that user or application. Proper automation and monitoring of the certificate lifecycle can stop this mistake from occurring.

    PKI as a Service

    One form of PKI becoming more and more common is PKI as a Service. The way PKI as a Service works is that a provider will have the PKI setup, whether at their own data center or within your organization, and handle all of the management and updating in the PKI. This allows the organizations purchasing this service to not need to train or hire PKI professionals, thus saving them money and manpower. If the PKI is setup at the provider’s data center, the organization purchasing their services will most likely have the PKI issue certificates to their users, without having their own Issuing CA. PKI as a Service is one of the many services provided by Encryption Consulting. We assist your organization in the design, implementation, and deployment of your PKI. Part of our PKI setup includes the use of an on-premises Thales-SafeNet, nCipher, or Utimaco HSM. We can implement it in our data center in Dallas, Texas, or onto your site. Whichever hardware security module you choose to use, they are all FIPS 140-2 Level 2 and 3 compliant, so you should reach all of your compliance requirements. Along with an HSM, we also help you build and design a backup for your PKI, for minimal to no loss of service from unseen circumstances. We can also implement different SIEM tools into your PKI, allowing you to monitor certificates and keys, to keep you up to date on revoked certificates, unused keys, etc. Our PKI as a Service can also be set up either on-premises or on the Cloud.

Root Certificates – Root vs Intermediate Certificates

Introduction

Public Key Infrastructures, or PKIs, are becoming many organizations security backbone, as they provide authentication and identification to the devices, individuals, or applications working within a company’s network. The way a PKI works, is a device, user, or application that wishes to work in an organization’s network sends out a Certificate Signing Request (CSR), which contains their public key, and the information needed to create a certificate for that user. The public key is part of a key pair created by the requestor, which is made up of a private and public key. The private key is kept secret from everyone, while the public key is used to match messages, certificates, or other communications signed by the private key to the corresponding public key. The CSR is sent to an Issuing Certificate Authority, or CA, which is in charge of issuing and managing certificates. Once the request, is accepted, the certificate is sent to the requestor.

how a CSR work

Figure 1: A diagram of how a CSR works

These certificates contain information about the certificate owner, including the Issuing CA’s name, the Certification Path, the requestor’s public key, and much more. Certificates share the identity of the certificate owner with other devices, applications, and users on the network, so that they know that the certificate owner can be trusted. This trust is ascertained via the Certification Path, or Certificate Chain of Trust, of the certificate issued to the certificate owner.

Understanding the Chain of Trust

As mentioned previously, part of a certificate is the Certification Path, or Chain of Trust, of the certificate. This Chain of Trust is a path linking the certificate owner’s certificate back to the Root CA’s certificate. The reason for a Chain of Trust is to give the inquiring service or user trust in the certificate whose chain they are following. When a web browser connects you to a website, the first thing they do is check that website’s certificate. If the certificate used by the website is found to be valid, the web browser then checks the Chain of Trust of the certificate. Though the certificate is still valid, the browser must verify the Intermediate, Issuing, and Root CAs’ certificates as well.

Figure 2: An example of a certificate

The below image is an example of what a Chain of Trust looks like. The certificate at the bottom named *.encryptionconsulting.com is this website’s certificate. The certificate named R3 is the Intermediate certificate, and the certificate named DST Root CA X3 is the Root certificate. Several components are checked on each of these certificates:

  1. The issuer of the currently viewed certificate must match the previous certificate’s name in the chain.
  2. The top of the chain must be a trusted certificate.
  3. The current certificate must be signed with the secret key of the previous certificate in the chain

Figure 3: An example of a Certification Path

The reason this is called the Chain of Trust is because the top of the chain gives implicit trust to the rest of the chain. The top certificate in a Chain of Trust is always a well-known and trusted Root CA that is explicitly trusted in the web browser’s certificate store. Since this Root CA is explicitly trusted, any certificates it issues can also be trusted implicitly. This is due to the fact that explicitly trusting a CA means that you also trust that it is only distributing certificates to other trusted sources. That implicit trust trickles down through the Chain of Trust and applies to all Intermediate and Issuing CAs within that chain, as well as the final certificate of the website being verified. Thus, a trusted and secure connection is made between the website and the web browser.

certificate chain

Certificate Management

Prevent certificate outages, streamline IT operations, and achieve agility with our certificate management solution.

Root Certificates

The Root Certificate is the core of the Chain of Trust, where all trust stems form. The Root Certificate is the certificate of a Root CA. These Root Certificates, or Trusted Certificates, are stored in certificate stores, also known as a Trusted Root Store. These stores contain the certificate and public key of all trusted roots and are pre-built in to the device’s Operating System or through third-party root stores within applications like web browsers. By building these Root Stores into the device before it is in use, the acceptance of many certificates is very quick, as most organizations that use public PKIs use the same ones that are already trusted. This means that any certificates signed by trusted Root CAs are automatically trusted.
Root Certificate Authorities are used to issue certificates to Intermediate and Issuing CAs. When establishing these other CAs, a cross-signed certificate is used as opposed to a regular certificate. A cross-signed certificate is a certificate that is signed by another CA, that is already trusted, for the newly created and untrusted CA. This allows a Certificate Chain of Trust to be created that leads back to an already trusted CA, until such time as the newly created CA has proved its trust and earned its own trusted certificate. Another important point about Root Certificates is that they are issued for a longer period of time than normal certificates. An average certificate is issued for a period of about 4 – 6 months. Root Certificates, on the other hand, tend to be issued for 20 years, as they need to stay valid longer so that the PKI doesn’t collapse.
Root CAs should also never issue certificates to end-users, as the compromise of a Root Certificate would shatter the entire PKI. If a threat actor were to take control of a Root Certificate, they could issue as many certificates as they wanted to any device. This would allow them to infiltrate a network completely undetected and steal sensitive information, plant malicious code into applications, or destroy important infrastructure.  Instead, Intermediate Certificates are used to issue certificates to end-users. Now, let us take a look at Intermediate Certificates.

Intermediate Certificates

Intermediate Certificates are given to Intermediate CAs, which do tasks that Root CAs would commonly do in the past. Since it is insecure to have more than one Root CA, multiple Intermediate CAs are created. Root CAs are kept offline at all times, so Intermediate CAs are act as online Root CAs, without the potential of crippling the entire PKI.
The way an Intermediate CA is created is simple:

  1. First, the Root CA signs the Intermediate CA’s certificate, the Intermediate Certificate, with its own private key, thus making that Intermediate Certificate trusted.
  2. The Intermediate CA now has the ability to use its Intermediate Certificate to sign end-user certificates.
    • Intermediate CAs can also sign other Intermediate CA’s Intermediate Certificates, creating more links in the Chain of Trust leading back to the Root Certificate.

Using Intermediate Certificate Authorities helps break apart the risk in using CAs. If you think of a PKI as a tree, if an Intermediate “Branch” were to be compromised, that “branch” could be pruned from the PKI, allowing the rest of the PKI to continue to exist. The “root” of the PKI, the actual Root CA, if infected would require the entirety of the CA to be replaced. Intermediate Certificates are vital to the creation of a solid and secure PKI. Intermediate CAs are stored the same as other certificates in the PKI, in a certificate store. A certificate store adds newly trusted CA certificates and end-user certificates to itself for easier certificate validation in the future.

Conclusion

As you can see, though they serve similar functions, Root Certificates and Intermediate Certificates are very different. Root CAs are kept offline and only issue certificates to Intermediate CAs, never to end-users, as their compromise would destroy the PKI. Intermediate CAs act as the online version of Root CAs, but with an Intermediate Certificate rather than a Root Certificate. Intermediate CAs can issue certificates to other Intermediate CAs, or to end-users, for whatever usage they need it for. Intermediate CAs are also slightly different from Root CAs in that their initial certificate is a cross-signed certificate, as opposed to a self-signed certificate, which is what the Root Certificate is. After proving its trust, the Intermediate CA is issued its own certificate, and does not need to rely on the cross-signed certificate any longer.

Without Root Certificates and Intermediate Certificates, the entire Chain of Trust of a PKI is broken. Intermediate CAs are needed for end-user interaction, while Root CAs form the base of the Chain of Trust. When contemplating the design of your own PKI, make sure you utilize both Root Certificates and Intermediate Certificates for the most secure systems possible. For any assistance needed with design and/or implementation of a secure Public Key Infrastructure, you can hire Encryption Consulting’s services. Our experienced team of experts can help you create your ideal PKI.

Cyber Security Attack Types – Active and Passive Attacks

There are two types of attacks that are related to security namely passive and active attacks. In an active attack, an attacker tries to modify the content of the messages. In a passive attack, an attacker observes the messages and copies them.

Passive Attacks

The first type of attack is passive attack. A passive attack can monitor, observe or build use of the system’s data for sure functions. However, it doesn’t have any impact on the system resources, and also, the data can stay unchanged. The victim is difficult to note passive attacks as this sort of attack is conducted in secret. Passive attack aims to achieve data or scan open ports and vulnerabilities of the network.

An eavesdropping attack is taken into account as a kind of passive attack. An eavesdropping attack is to steal data transmitted among two devices that area unit connected to the net. Traffic analysis is enclosed in eavesdropping. An eavesdropping attack happens once the attackers insert a software package within the network path to capture future study network traffic. The attackers have to be compelled to get into the network path between the end point and the UC system to capture the network traffic. If their area unit additional network methods and also the network methods area unit longer, it’ll be more comfortable for the offender to insert a software package within the network path.

The release of messages is additionally another kind of passive attack. The attackers install a package to the device by using virus or malware to watch the device’s activities like a conversation of messages, emails, or any transferred files that contain personal information and knowledge. The attackers will use the data to compromise the device or network.

Some other attacks that have emerged thanks to the exponential interconnection of insecure devices like IoT infrastructure include those that square measure protocol-specific, likewise as wireless device networks-based

For example, in associate IoT-based, mostly sensible-home systems, the communication protocol used is also RPL (Routing protocol for low-power and lossy networks). This protocol is employed thanks to its compatibility with resource-constrained IoT devices that cannot use ancient protocols.

Tailored Encryption Services

We assess, strategize & implement encryption strategies and solutions.

Active Attacks

An active attack could be a network exploit during which the attackers will modify or alter the content and impact the system resource. It’ll cause damages to the victims. The attackers can perform passive attacks to gather info before they begin playacting a vigorous attack. The attackers attempt to disrupt and forced the lock of the system. The victims can get informed concerning the active attack. This sort of attack can threaten their integrity and accessibility. A vigorous attack is tougher to perform compared to a passive attack.

Denial-of-Service attacks (DoS) are one in each of the samples of active attack. A denial-of-Service attack happens once the attackers take action to close up a tool or network. This may cause the first user to be unable to access the actual device or network. The attackers can flood the target device or network with traffic till it’s not responding or flaming. The services that are affected are emails, websites, or on-line banking accounts. Dos attacks may be performed merely from any location.

As mentioned on top of, DoS attack includes flooding or flaming the device and network. Buffer overflow attack is one in every of the common DoS attacks. This sort of flooding attack sends a lot and a lot of traffic to the network that exceeds the limit that a buffer will handle. Then, it’ll lead to a flaming of the system. What is more, ICMP flood, called ping flood, is additionally a kind of flooding attack. The assaulter can send spoofed packets and flood them with ICMP echo requests. The network is forced to reply to all or any claims. This may cause the device not to be accessible to traditional traffic.

Moreover, SYN flood is additionally a kind of flooding attack. The attackers can keep generating SYN packets to all or any of the ports of the server. Faux informatics addresses are usually used. The server that is unaware of the attack can then reply to the SYN-ACK packets. The server can fail to access the shoppers and therefore crash. Applied math approaches may be prone to develop attack detection techniques for attacks like SYN flood. One such technique is projected by authors wherever they need projecting SYN flood attack detection theme supported Bayes calculator for unintended mobile networks.

Trojan horse attacks are another example of network attack, the most ordinary sort of that is backdoor trojan. A backdoor trojan permits the attackers that don’t have the authority to realize access to the pc system, network, or code application. As an example, the attackers may hide some malware in an exceedingly explicit link. Once the users click the link, a backdoor is going to be downloaded within the device. Then, the attackers can have basic access to the device. Apart from that, a rootkit is additionally another example of a trojan attack. A rootkit is usually won’t to get hidden privileged access to a system. It’ll give root access to the attackers. The attackers can manage the system; however, the users won’t get informed of it. They will amend any settings of the pc, access any files or photos, and monitor the users’ activities. A number of the favored rootkit examples are Lane Davis and Steven Dake, NTRootKit, philosopher Zeus, Stuxnet, and Flame. Flame a malware that’s established within the year 2012 that is intended to attack Windows OS. It will perform some options like recording audio, screenshotting, and observance network traffic.

Moreover, a replay attack is one in every one of the samples of active attack. The attackers can snoop on a specific user before they begin playacting a replay attack. Then, they’re going to send to the victim Associate in Nursing the same message from Associate in Nursing authorized user, and the message is appropriately encrypted. Replay attacks enable the assaulter to possess access to the information and knowledge keep within the compromised device. They can also gain money profit as they’re able to duplicate the group action of the victim. This as a result of the attackers can listen to the frames of this session, mistreatment constant info to perform the attack while not limiting the number of times. There’s another attack referred to as a cut-and-paste attack that is comparable to a replay attack. In a cut-and-paste attack, the assaulter can mix different ciphertext elements and send them to the victim. The assaulter can then get the data they require and use them to compromise the system.

Conclusion

Cybersecurity is a big part of our lives today. It is crucial to protect our devices from these malicious activities of attackers. Active and Passive attacks are challenging issues in any organization. Any Advanced Persistent Threat (APT), always chooses passive attack first to gain information about the infrastructure and the network, which can then be used to fabricate a targeted active attack against the said infrastructure, which often can be hard to block or cause catastrophe to the organization.

Time Stamping Code Signing Certificates – Significance

Introduction

Let’s briefly discuss Code signing.

Code signing is a method of putting a digital signature on a file, document, software, or executable to test its authenticity and genuineness in regards to the functionality and features that it provides. This also ensures that the software entity (file, document, software, or executable) is not tampered with while in transit.
Code signing has become a quintessential requirement for software developers, The reason is code signing ensures a trust among users for the software, and also provides confidence to users to avoid the warning messages which appear when a user downloads/installs the executable in their environment.

What is Time Stamping?

Time stamping is an optional part of the code signing process, which allows software to recognize whether an applied code signing signature is valid–even after a code signing certificate expires. In other words, we can say that time stamping preserves the signature applied to the software.
Whenever the signed software’s executable is run/executed on any client machine/system, its digital signature is verified by the user’s operating system. Now, suppose the user has time stamped the software. The users’ computer will verify the signature based on the time it was digitally signed, rather than the current time of the system when the software is executed.

Below is the work flow for a time stamping process:

Time Stamping is provided by the Time Stamp Authority (TSA) which uses Public Key Infrastructure (PKI) principles and technology for applying timestamps.

Enterprise Code-Signing Solution

Get One solution for all your software code-signing cryptographic needs with our code-signing solution.

The following steps are performed to Time Stamp software:

  1. A hashed value is created and sent to the TSA by the requester for the software that needs to be time stamped.
  2. Hash value, authoritative time and other related information such as data and time of the digital signature are combined by the TSA and signed by its private key to create a new hash value.
  3. Next, the new hash and the software’s hash is bundled up and sent to the requester.
  4. A requester’s application then receives the bundle and verifies it. Once the verification is done, the time stamp becomes valid and embedded within the code signature of the software.

Let’s try to understand this in terms of a real-world scenario.
Let’s assume that you are the developer, you did the code signing of your software, and the certificate is valid from January 2021 to till January 2022. Now, a user who downloads your software on October 2021 forgets to install it due to his busy schedule. He tries to install the software in February 2022, but he gets an error.

Let’s understand the same scenario with the only exception that you have time stamped the software in July 2021. Now, when the user tries to install the software in February 2022, he is able to install it and doesn’t get any error at all. This is the effect of Time Stamping!!

Protocols used in Time Stamping

The following protocols are used in Time Stamping software:

RFC 3161

RFC 3161 is updated and designated as RFC 5035 which additionally allows the use of ESSCertIDv2.

Microsoft Authenticode

Microsoft Authenticode can be utilized in various formats such as .cab, .exe, .ocx, and .dll

Code Sign Time Stamping best practices

The following best practices can be adapted while Code sign Time Stamping is done:

  1. Always make sure that the time stamping option is enabled in your signing tool, such as Microsoft Signtool. Also, choose a signing tool which supports the time stamping option as it’s an optional feature by default.
  2. Ensure that time stamping is included as part of your software development lifecycle process. This will avoid any unexpected issues occurring due to version mismatches.
  3. Document the complete process for your signing tool while using the time stamping option, as every sign tool has a different workflow for time stamping. Also, distribute this document to every stakeholder involved in the code signing process.
  4. Time stamping allows the client system to verify if the software was signed before or after the revocation of the code signing certificate. So, if you want to revoke the code signing certificate for any reason, such as private key compromise, you may do so. The client system will not have any difficulty while installing the software, as time stamping was done when the code signing certificate was valid.

Conclusion

Time stamping appears to be an optional step, whereas it is a vital component of the code signing ecosystem in your organization. Without time stamping, expiration/revocation of code signing certificates would lessen the confidence of customers in the same software product. Timestamps make sure that even if certificates lose their validity or are revoked for some reason, their signatures remain valid, secure and trusted.

PKI Fundamentals – Knowing the Modern PKI

Public Key Infrastructures (PKIs) are necessary to verify the identity of different people, devices, and services. In a nutshell, PKIs go way beyond the use of user IDs and passwords, employing cryptographic technologies such as digital signatures and digital certificates to create unique credentials that can be validated beyond reasonable doubt and on a mass scale.
Before we deep dive into Modern PKI demand, lets understand:

What is PKI?

PKI stands for Public Key Infrastructure. Public Key Infrastructure is a solution where, instead of using an Email ID and Password for authentication, certificates are used. PKI also encrypts communication, using asymmetric encryption, which uses Public and Private Keys. PKI deals with managing certificates and keys and creates a highly secure environment that can also be used by users, applications, and other devices. PKI uses X.509 certificates and Public Keys, where the key is used for end-to-end encrypted communication, so that both parties build trust each other and test their authenticity.

Private and Public PKI

Organizations trying to come up with a Public Key Infrastructure (PKI) plan are often confronted with the choice between public and private PKI.
Today, most organizations take a hybrid approach, using a mix of digital certificates from both public and private CAs. As a result, it has become much more challenging to know how many certificates you have, where they reside, and whether they are compliant. Although following best practices is mandatory while deploying a solution, it is next to impossible when you are too busy chasing down application owners to renew certificates or recover from the latest outage.

Previously, the IT team of an organization had to sit and discuss the CA hierarchy (Two-tier or Three-tier hierarchy) of their PKI Infrastructure. In the modern world, with so many successfully deployed and managed PKIs, it has become easier to understand which hierarchy should deployed for an organization, based on their business needs. Today, most PKI deployments are two-tier. The three-tier architecture comes into the picture only when there is a specific technical/industrial requirement of the organization. Nowadays, as per the standard practice, it is also important to implement HSMs to store Private Keys and protect CAs, as attackers have realized the value of using private keys to breach enterprise networks.

In this article we will talk about the Modern demands for PKI, such as does your PKI fulfil all your needs, what do you use it for, etc.

Modernize your PKI

PKI is one of the most critical security tools for an organization. As the use cases continue to grow, it is important that the organization take the right expertise to keep the PKI up and running securely.
Encryption Consulting has the right expertise and helps customers deploy or migrate from Traditional PKI to a fully managed PKI, or to a highly scalable PKI-as-a-Service platform in the cloud.

A new cloud-based approach to PKI

Encryption consulting helps building and manage PKI infrastructure in the cloud as per the customers business requirements. For a two-tier based PKI model, the Root CA is offline and kept On-prem, where the issuing CA resides on the cloud. In the approach that is mentioned below, the Root CA is offline and kept On-prem. There are also two issuing CAs which were deployed, one of which is on-prem while the other is in the cloud. The on-prem CA will have security focus on non-cloud resources (such as workstation authentication etc.) and the other issuing CA will be focus on the cloud resources. Keys are secured in HSMs.


Unlike on-premises counterparts, cloud-based PKIs are externally hosted PKI services, supplying PKI capabilities on demand. The cloud-based approach drastically reduces the burden on individual organizations – financially, resource-wise, and timewise, by eliminating organizations’ need to set up any infrastructure in-house. The service provider handles all the ongoing maintenance of the PKI while ensuring scalability and availability – providing a hassle-free, efficient service.
Scalability to match the growing needs of the organization is another advantage. The service provider handles all additional requirements – installing software, hardware, backup, disaster recovery, and other infrastructure – that would otherwise become a burden for owners of on-premises PKI solutions.

To Learn more about Cloud-based PKI visit :

www.encryptionconsulting.com/cloud-based-public-key-infrastructure-architecture/

Enterprise PKI Services

Get complete end-to-end consultation support for all your PKI requirements!

The advantages of PKI-as-a-Service

  1. Reduces Cost & Complexity

    A quicker deployment of your PKI infrastructure, less in-hours issues, reduces spending for in-house PKI, and periodic PKI assessments and trainings are all offered with PKI-as-a-Service.

    Enhance security posture with a trusted, privately rooted PKI deployed with industry best practices.
  2. Dedicated Security Expert

    Security Experts will be assigned to the service, offering consistent and flexible support to meet customer requirements and demands.

    Reduced time and frustration spent on PKI-related tasks such as CA and CRL maintenance is also offered by a dedicated security expert.
  3. Scalability and Flexibility

    Provides observations and recommendations regarding current and future initiatives to help achieve desired future state capabilities.

    Integrate your PKI with devices and applications using REST APIs, plug-in integrations, and standard enrollment protocols.

Additional Services

  • Sub CA signings
  • Root CA and sub CA certificate lifecycle management advice (e.g. hashing algorithms / cryptographic algorithms)
  • Policy / certificate profile advice
  • Root maintenance
    • Root migration / rollover

Encryption Consulting’s Managed PKI

Encryption Consulting LLC (EC) will completely offload the Public Key Infrastructure environment, which means EC will take care of building the PKI infrastructure to lead and manage the PKI environment (on-premises, PKI in the cloud, cloud-based hybrid PKI infrastructure) of your organization.

Encryption Consulting will deploy and support your PKI using a fully developed and tested set of procedures and audited processes. Admin rights to your Active Directory will not be required and control over your PKI and its associated business processes will always remain with you. Furthermore, for security reasons the CA keys will be held in FIPS140-2 Level 3 HSMs hosted either in in your secure datacenter or in our Encryption Consulting datacenter in Dallas, Texas.

Conclusion

Encryption Consulting’s PKI-as-a-Service, or managed PKI, allows you to get all the benefits of a well-run PKI without the operational complexity and cost of operating the software and hardware required to run the show. Your teams still maintain the control they need over day-to-day operations while offloading back-end tasks to a trusted team of PKI experts.