Reading time: 3 minutes

In this blog, we’ll discuss the issues faced while scheduling backups on CipherTrust Manager.

Error

codeDesc: NCERRInvalidParamValue

errorMessage: Specified backup key does not exist for scope (system)

Description

Let’s consider that we have 4 CipherTrust Manager nodes (thales01.ec.com, thales02.ec.com, thales03.ec.com, thales04.ec.com)  in a cluster. As per the procedure, we’ll have to create a system backup schedule on any of the nodes, which will further get replicated on others.

Note: Backups and backup keys are not replicated across the cluster.

Cause

The primary reason for this error is that the backups occur randomly on any one of the nodes, and if the backup key isn’t present on that particular node while it is being initiated, the backup will fail.

CipherTrust Manager Backup Error

Solution

Let’s assume we are scheduling a backup from thales01.ec.com. To resolve this error, please follow the below-mentioned steps

  1. On thales01.ec.com, navigate to the Backup keys under Admin settings.

    Backup keys
  2. First, create a new system backup key and make it as default.

    system backup key
  3. Download the newly created system backup key in order to upload them on other CipherTrust Manager cluster nodes.

    cluster nodes
  4. Enter a password for the corresponding backup key and click “Download.”

    Download backup keys
  5. Now, follow the below-mentioned path to upload the system backup key on all the CipherTrust Manager cluster nodes.

    Choose the downloaded file and enter the password generated in the previous step for the uploaded backup key.

    step for the uploaded backup key
  6. Navigate to Admin Settings Schedules to schedule a system-level backup.

    system level backup
  7. Click on “Add Schedule.”

    Schedules
  8. Select “System Backup” and click “Next.”

    System Backup Schedule
  9. Enter the “Schedule Name” and click “Next.”

    cipher trust schedule name
  10. Determine the backup frequency and click “Next.”

    backup frequency
  11. State the number of backups to retain and select “Use default backup key.”

    Note: “Use default backup key” will help perform a successful backup on any cluster node since the default key is the same on all of them.

    Use default backup key

Free Downloads

Datasheet of Encryption Consulting Services

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

Download
Encryption Services

About the Author

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

In this blog, we’ll discuss the issues of clustering encountered during CipherTrust Manager installation and configuration.

Error

  1. A generic connection error occurred while creating the cluster. This type of error typically occurs when the host is invalid. Please retry using a valid IP or hostname. Code 8: NCERRInternalServerConnectFailed
  2. Failed self-connection check. This type of error typically occurs when the host is invalid. Please retry using a valid IP or hostname. Code 8: NCERRInternalServerConnectFailed

Description

Let’s consider that we have 4 CipherTrust Manager nodes (thales01.ec.com, thales02.ec.com, thales03.ec.com, thales04.ec.com)  to add to a cluster. As per the procedure, we’ll have to select one of the nodes to create a cluster and, after that, add all the remaining nodes to that cluster. Usually, we have two options for calling out each of the appliances.

We can either mention the hostname of the CipherTrust manager or the IP address. It is, however, recommended to use the hostname instead of the IP address from a networking standpoint. The errors mentioned above are encountered during the cluster creation process when the hostname of the CipherTrust Manager is entered.

Cause

The primary reason for these errors is that the CipherTrust Manager cannot recognize the hostname. A user might encounter this issue despite setting up a DNS and a proper hostname.

Cluster
cluster error

Solution

Let us assume we are creating a cluster from thales01.ec.com and adding all other nodes from this server. To resolve this error, please follow the below-mentioned steps:

  1. On thales01.ec.com, navigate to DNS hosts under Admin settings.

    CipherTrust Manager Admin settings
  2. First, add all 4 CipherTrust Manager hostnames.

    CipherTrust Manager hostnames
  3. Navigate to clustering and try creating the cluster again with the hostname of the primary node (thales01.ec.com).

    clustering
  4. After creating a cluster, we will add other nodes by using their hostname from thales01.ec.com. To complete this process successfully, we’ll first have to add the primary node (thales01.ec.com) on each of the secondary nodes (thales02.ec.com,thales03.ec.com, thales04.ec.com) and then add the secondary node itself

    under Admin settings-> DNS Hosts. The concept behind adding the same is for both nodes to recognize themselves as well as each other.

  5. Once the cluster is created, all the nodes have been added, and the testing has been completed, you can delete all the DNS hosts added on each of the CipherTrust Manager appliances and check that clustering is functioning properly.

Free Downloads

Datasheet of Encryption Consulting Services

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

Download
Encryption Services

About the Author

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

Reading time: 5 minutes.

SSH stands for Secure Shell or Secure Socket Shell. It is a cryptographic network protocol that allows users and sysadmins to access computers over an unsecured network such as the Internet. It is used to log in to a remote server, execute commands, and transfer data from one machine to another.

Where do we use SSH?

SSH is used to replace unprotected remote login protocols like Telnet, rlogin, rsh, and others, as well as insecure file transfer protocols like FTP. Network administrators extensively utilize its protection capabilities. We can use SSH protocol in various scenarios, such as:

  • Enabling secure access for users and automated processes
  • Performing interactive and automated file transfers
  • Issuing remote commands
  • Managing network infrastructure and other mission-critical system components

How does SSH work?

The SSH protocol works on a client-server architecture, so an SSH client establishes a secure connection to an SSH server. The SSH client drives the connection establishment process and uses public key infrastructure (PKI) to verify the authenticity of the SSH server. Once configured, the SSH protocol uses strong symmetric encryption and hashing algorithms to ensure the confidentiality and integrity of data exchanged.

What are the different types of authentication?

Key-based authentication

The most commonly used form of SSH deployment is public key authentication. It is preferred over simple passwords because of enhanced security. Key-based authentication provides unmatched cryptographic strength, which is even more than that offered by very long passwords. SSH greatly increases security through public key authentication, eliminating users’ need to remember complex passwords.

In addition to security, public key authentication improves usability. This allows the user to implement single sign-on across the SSH servers he connects to. Key-based authentication also enables automated passwordless logins, a key feature of the myriad of secure automated processes running in corporate networks worldwide.

This type of authentication generates a key pair (public and private key).

  • The public key is copied to the SSH server and, by default, added to the ~/.ssh/authorized_keys file. Anyone who has a copy of the public key can encrypt data that can only be read by those who have the corresponding private key.
  • The private key remains (only) with the user. Only a user whose private key corresponds to the server’s public key can authenticate successfully. Private keys should be stored and handled carefully, and copies of private keys should not be distributed.

Disadvantages of key-based authentication

  • Poor SSH key management can pose a great risk to organizations.
  • Misuse of SSH keys can lead to confidential or privileged information access.
  • Since keys are trusted permanently, it increases the chances of an attack.

Certificate-based authentication

This type of authentication does not need key approval and distribution. Instead of distributing public keys across static files, we can use certificates to bind public keys to names. A certificate contains data such as a public key, a name, and additional data such as expiration dates and permissions. This data is signed by a certification authority (CA).

To enable certificate authentication, configure clients and hosts to verify certificates using your CA’s public key (i.e., trust certificates issued by your CA).

On each host, edit /etc/ssh/sshd_config, specifying the CA public key for verifying user certificates, the host’s private key, and the host’s certificate.

On each client, add a line to ~/.ssh/known_hosts specifying the CA public key for verifying host certificates.

Advantages of certificate-based authentications

  • It is simple to use as a trust on first use (TOFU) warnings are not displayed because certificate authentication uses certificates to communicate public key bindings, allowing clients to authenticate at all times.
  • It streamlines operations by eliminating the key approval and distribution process. It also reduces the operational cost of monitoring and maintaining current infrastructure for adding, removing, synchronizing, and auditing static public key files.
  • It promotes good security hygiene as compared to key-based authentication. The chances of a compromised private key going unnoticed for a long time is quite likely; however, certificates, on the other hand, expire, which means in case of theft, misuse, etc., it will automatically expire, thereby making it fail-secure.

Conclusion

Certificate-based authentication has many benefits, such as improving usability, enhancing security, streamlining operations, etc. If implemented, it will help organizations reduce complexities of key approval and distribution, improper key management-related risks, and much more.

Free Downloads

Datasheet of Encryption Consulting Services

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

Download
Encryption Services

About the Author

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

Certificate enrollment is the process by which a user requests a digital certificate from a Certificate Authority (CA). There are several methods for enabling certificate enrollment ranging from manual methods that are initiated by a user performing the certificate request to automatic methods where the certificate request is initiated by Group Policy or a login script. Manual enrollment is not well suited for mass certificate deployment because of the amount of time an organization must spend training personnel to use such a method. In contrast, Autoenrollment, on the other hand, lowers the cost of a PKI by reducing the time and effort required to deploy certificates.

Certificate Enrollment Methods

  1. Certificate Services Web Enrollment Pages

    Certificate Services Web Enrollment pages allow a user to request both user and computer certificates from a Web browser. Certificate Services Web Enrollment pages allow the requestor to ask for specific certificate templates from an enterprise CA, submit certificate request files from a network device or another operating system and check on pending certificate requests.

  2. Certificate Enrollment wizard

    This wizard permits a user to request certificates from an enterprise CA by selecting the enterprise CA and the certificate template and defining additional settings, such as key length and CSP. The wizard can be launched from the Certificates Microsoft Management Console (MMC) console.

  3. Automatic Certificate Request Settings (ACRS)

    This Group Policy setting allows the automatic deployment of version 1 computer certificates to computer accounts in the forest. The computer account must be in the domain or organizational unit (OU) where the Automatic Certificate Request Settings is defined. In addition, the computer account must belong to a group that is assigned the Read and Enroll permissions for the version 1 certificate template.

  4. Autoenrollment settings

    This combination of version 2 and version 3 certificate templates and Group Policy settings allows the automatic deployment of certificates to users and computers. All computers or user accounts within the domain or OU where the Autoenrollment Settings Group Policy setting is applied automatically receive any published version 2 or version 3 certificate templates to which the user or computer account is assigned Read, Enroll, and Autoenroll permissions. Autoenrollment can be used for initial certificate deployment as well as for certificate renewal.

  5. Certreq.exe

    This command-line tool allows a user to create, submit, retrieve, and accept certificate requests sent to a Windows Server CA. The requests can be sent to both standalone and enterprise CAs.

  6. Network Device Enrollment Service (NDES)

    NDES is a new Certificate Services role service that enables enrollment through Simple Certificate Enrollment Protocol (SCEP), an open-source certificate management protocol.

  7. Registration authorities

    Registration authorities allow custom workflows to be defined for certificate life-cycle management tasks. A registration authority ensures that any required data collection and approvals are collected before a certificate management task is processed.

Automatic Enrollment

Before enrolling a certificate manually, automatically, or through a scripting method, you must ensure that the certificate templates are available for enrollment at a CA.

Two methods for automatically deploying certificates to users and computers are:

  1. Automatic Certificate Request Settings

    Automatic Certificate Request Settings (ACRS) is an automated enrollment process to distribute certificates automatically, but the supported scenarios are limited:

    • Certificates can be distributed to computers running Windows 2000 and later that are domain members.
    • Only version 1 certificate templates can be distributed.
    • Certificates cannot be distributed to user accounts. Although limited, ACRS is useful for distributing Computer or IPsec certificates to all computers in a domain
  2. Autoenrollment Settings

    Autoenrollment Settings is a combination of Group Policy settings and version 2 or version 3 certificate templates. The combination allows the domain member client computer to automatically enroll user or computer certificates.

Enrollment Protocols

  • SCEP

    Simple Certificate Enrollment Protocol (SCEP) is an open-source certificate management protocol that is used for automating the task of certificate issuance.

  • EST

    Enrollment over Secure Transport protocol (EST) is the evolution of SCEP and uses Transport Layer Security (TLS) for client-side device authentication.

  • ACME

    Automated Certificate Management Environment (ACME) provides an efficient way to validate that a certificate requester is authorized for the requested domain and automatically installs the certificates

Conclusion

Generally, automatic enrollment is preferred by organizations; however, if the requestor cannot communicate directly with the CA or the device does not support auto-enrollment, the manual enrollment method can be opted for.

Free Downloads

Datasheet of Encryption Consulting Services

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

Download
Encryption Services

About the Author

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

Read Time: 5 minutes

Certificate revocation is the process in which a certificate’s usage is terminated before the validity period expires. The choice to revoke involves knowing the available revocation reasons, mapping the revocation reasons to your organization’s revocation policy, and then performing the revocation.

Reasons for certificate revocation

Certificates are revoked by declaring them invalid if the relying parties are not using them. There can be multiple reasons for revoking a certificate which are:

  1. AffiliationChanged

    An individual is terminated, resigns, or dies, or the computer account to which the certificate was issued is no longer in use. These revocation reasons can also be used if a person changes roles within an organization and no longer requires using the certificate associated with that person’s previous role.

    For example, an employee could move from the purchasing department and no longer require a certificate to authorize purchase requests.

  2. CACompromise

    You suspect that a CA’s private key has been compromised and is in the hands of an unauthorised individual. If a CA’s private key is revoked, the CA hierarchy considers all certificates below that CA (Certificate Authority) revoked.

  3. CertificateHold

    A temporary revocation that indicates a CA will not validate a certificate at that specific time.

    Note: Although CertificateHold allows a certificate to be unrevoked, using the CertificateHold reason code is not recommended because it makes determining whether a certificate was valid at a specific time difficult.

  4. CessationOfOperation

    A server or workstation is decommissioned, and all certificates issued to the server are no longer required. When decommissioning a CA, you can also use this revocation reason.

  5. KeyCompromise

    You suspect that the private key associated with a certificate is compromised.

    For example, if a laptop belonging to a user in your organization is stolen, any private keys stored on the laptop may be compromised.

  6. RemoveFromCRL

    You can unrevoke a certificate that you revoked using CertificateHold. The certificate is still listed in the CRL after the unrevocation process, but it also appears in a delta CRL with the revocation code set to RemoveFromCRL. The CA removes the certificate from all forms of the CRL when the next base CRL is published. If delta CRLs are not used, the certificate is removed from the following base CRL.

  7. Superseded

    A new certificate must be issued if an issued certificate is replaced for any reason with a new updated certificate. For example, if you update a certificate template and reissue certificates, you could revoke the previous certificate with this reason code.

  8. Unspecified

    You can revoke a certificate without providing a specific revocation code. However, Unspecified is not recommended because it does not provide an audit trail identifying why a certificate was revoked.

How to perform certificate revocation?

To revoke a certificate, a user must be designated as a certificate manager. You designate a user as a certificate manager by assigning the user or a group containing the user the Issue and Manage Certificates permission at the issuing CA. The permission assignment is performed by a CA Administrator, which is a user assigned the Manage CA permissions. Perform the following steps to provide the necessary permissions:

  1. From Administrative Tools, open the Certification Authority console.

    Manage CA permissions
  2. In the console tree, right-click CAName (where CAName is the logical name of the CA) and then click Properties.

    Manage Certificates permission at the issuing CA
  3. In the CAName Properties dialog box, select the Security tab to ensure that the user account or a group that the user is a member of is assigned the Issue and Manage Certificates permission.

    Manage Certificates permission.

Once you assign the necessary permissions, the following procedure revokes a certificate:

  1. From Administrative Tools, open the Certification Authority console.

    Manage CA permissions
  2. In the console tree, expand CAName and click Issued Certificates

    CAName
  3. In the details pane, find the certificate you need to revoke, right-click the certificate, point to All Tasks, and click Revoke Certificate.

    certificate you need to revoke
  4. Select the appropriate reason code in the Reason Code drop-down list in the Certificate Revocation dialog box, and then click Yes.

    Certificate RevocationEncryption Consulting Certificate Revocation
  5. Check if the certificate revoked recently is visible in the revoked certificates section.

    revoked certificates

How to identify revoked certificates?

Public key infrastructure (PKI) provides three ways to determine if a certificate has been revoked:

  • Base CRL

    Certificate Revocation List (CRL) contains the serial numbers of certificates revoked by the CA that are signed with the CA’s private key. If you renew a CA’s certificate with a new key pair, the CA maintains two separate CRLs—one for each key pair maintained by the CA. All versions of the Microsoft Windows operating system recognize base CRLs.

  • Delta CRL

    This contains only the serial numbers of certificates revoked by the CA since the last base CRL publication. Again, if the CA’s certificate is renewed with a new key pair, separate delta CRLs are maintained for each CA key pair. Delta CRLs allow you to publish revocation information quicker and allow smaller updates to be downloaded by client computers.

  • OCSP

    Online Certificate Status Protocol (OCSP) provides a responder service that can either connect directly to a CA database or inspect the base and delta CRLs published by the CA to determine the revocation status of a specific certificate.

Conclusion

We must revoke the certificates when not being used by relying on parties to prevent the attackers from impersonating themselves and causing significant damage. For more information, please get in touch with us at: info@encryptionconsulting.com

Reference: PKI and certificate security by Brian Komar

Free Downloads

Datasheet of Encryption Consulting Services

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

Download
Encryption Services

About the Author

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

Reading time: 5 minutes

The Network Device Enrollment Service (NDES) allows software on network devices, such as routers, firewalls, switches, etc., to obtain digital certificates without running any domain credentials. NDES is also one of the role services on Active Directory Certificate Services (AD CS). It implements the Simple Certificate Enrollment Protocol (SCEP), which defines the communication between the Registration Authority (RA) and network devices for certificate enrollment.

Functions of NDES

NDES performs the following functions:

  1. Generates and provides one-time enrollment passwords to administrators
  2. Submits enrollment requests to the Certificate Authority (CA)
  3. Retrieves enrolled certificates from the CA and forward them to the network device

Best Practices

Enable SSL for the NDES administrator site

SSL protection ensures that the enrollment challenge password is protected against inspection attacks when the network device connects to the MSCEP_Admin Web site.

Create extended validity period device certificates

The default IPsec (Offline Request) certificate template has only a one-year validity period. If you define custom signing, encryption, or general-purpose certificate templates, consider creating a version 2 certificate template with a two-year validity period. A longer validity period reduces the management overhead for requesting device certificates.

Disable the NDES service when not in use

Stopping the NDES service ensures that unauthorized certificates will not be issued. Stopping the service also ensures that all data, such as all passwords that were not used by network devices, is cleared from the service cache.

Use the Security Configuration wizard to lock down the server

The Security Configuration Wizard will recommend locking down IIS and other services installed on the NDES server.

Implement Role Separation

Various accounts involved in installing, configuring, and operating NDES:

  • Setup Account
  • Device administrators
  • NDES account
    • Network Service
    • Group Managed Service Account (gMSA) or
    • Domain user account

Recommendations based on the choice of NDES account

  • AES encryption is required for gMSA or Domain user accounts.
  • Configure login restrictions and a long password for domain user accounts
  • Do not use gMSA or Domain user accounts on any other computers or for any other purposes
  •  Enable the “Account is sensitive and cannot be delegated” checkbox for Domain user accounts.
  • Remember to manually configure permissions on the NDES’ certificates’ private keys when using a gMSA or custom certificate template.

Ensure system hardening

Reduce the number of local admins groups to include only PKI Admins. Only members of the PKI Admins group are granted any logon user rights (interactive, remote interactive, log on as a batch job, log on as a service).

Secure the keys

The following practices should be implemented to secure the keys:

  • It is strongly advised to use a Hardware Security Module (HSM) to generate, store, and manage access to NDES keys. HSMs ensure that the NDES keys never reside in the operating system’s memory, provide additional operational controls, and limit exposure to the key material.
  • If the NDES is virtualized, it is recommended that HSM should be used to store NDES private keys as the keys can be found in an unencrypted version by Virtualization’s host admins who have access to VM, disk, and memory.
  • Backups must be encrypted, and access should be extremely limited in case an HSM is not being used to store private keys, as Snapshots/Checkpoints and other types of backup typically contain the NDES’ private keys

Infrastructure

The following practices should be followed with respect to infrastructure for NDES:

  • When allowing Internet access to NDES (for example, to enroll certificates in Intune-managed mobile devices), ensure that NDES is properly protected using a reverse proxy (such as Azure AD Application Proxy or Web Application Proxy (WAP)).
  • NDES should be installed on a different computer than the one hosting the CA service. Furthermore, no other services should be running on the computer that hosts NDES.
  • If NDES is deployed on a CA computer, configure the Certification Authority Enrollment and Management Protocol (CERTSVC-RPC-TCP-IN) firewall rule so that only the NDES (and OCSP) IP address can access the CA for enrollment.

Certificate Authority & Certificate templates

The certificate templates assigned by default during the configuration of NDES are:

  • CEP encryption: A certificate based on this template is issued to the NDES computer during the configuration of the service. It is used to apply SCEP-specific encryption to the communication with the requesting client. 
  • Exchange Enrollment Agent (Offline request): A certificate based on this template is issued to the NDES computer during the configuration of the service. The NDES uses it to digitally re-sign the enrollment request received from the device or MDM. After that, the re-signed enrollment request is forwarded to the issuing CA.

Note: Both of the above templates are used only during the initial installation of NDES and when renewing the certificate before it expires—Un-assign these templates from the CA during normal operating times. The Setup Account needs to have Enroll permissions on this template during the configuration of NDES. 

IPSec (Offline Request) aka “Device Template” aka “SCEP Certificate Template”

This certificate template is used for enrolling device or user certificates and is automatically assigned to the CA during NDES configuration. Most of the time, you’ll decide to replace it with a certificate template that better suits your needs. The Device administrator and NDES Service Account need to have Enroll permissions on this template.

Implement Data-in-transit encryption

TLS must be used to encrypt communication between NDES and MDM/the device requesting the certificate. This includes the following:

  • Enforcing TLS by disabling IIS’s HTTP listener
  • TLS 1.2 Compliance

Conclusion

We should implement all the above-mentioned best practices to secure NDES. It is extremely important to protect the private keys as any malicious person who gets access to it will be able to request a valid certificate for logging into the Active directory with any subject.

Reference

NDES Security Best Practices – Microsoft Community Hub

If you need help with your PKI environment, feel free to email us at info@encryptionconsulting.com.

Free Downloads

Datasheet of Encryption Consulting Services

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

Download
Encryption Services

About the Author

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

Reading time: 3 minutes

What is PKCS #12?

PKCS #12 is an archive file format used for storing multiple cryptography objects in a single file. The filename extension for PKCS #12 files is  .p12 or .pfx

What is a PFX file?

A .pfx file is a bag that can hold many objects with optional password protection; however, a PKCS#12 archive usually contains a certificate and the corresponding private key. The file can also include CA chain certificates as well.

What is a PEM file?

PEM is a base64 encoded certificate placed between the headers —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—–. The following file extensions are possible for PEM certificates:*.pem, *.crt, and *.cer

How to convert PFX file to PEM format?

Scenario 1: Export private key and certificate files from PFX file

The following procedure will convert the PFX-encoded certificate file into two files in PEM format.

  • certconvert.pem – PEM file containing the SSL/TLS certificate for the resource.
  • privatekeyconvert.pem – PEM file containing the private key of the certificate with no password protection.

Prerequisites

We use an OpenSSL toolkit to convert a PFX encoded certificate to PEM format. For testing this scenario, we use a password protected PFX-encoded file – certificatepfx.pfx and a 2048-bit RSA private key.

Commands

For exporting key:

openssl pkcs12 -in certificatepfx.pfx -nocerts -out privatekeyconvert.pem -nodes

Snippet of output

For exporting certificate

openssl pkcs12 -in certificatepfx.pfx -clcerts -nokeys -out certconvert.pem

Snippet of output

Note: Optionally, we can also have CA certificate chain as a part of the PFX file. In order to export it from the PFX file we run the following command:

openssl pkcs12 -in certificate.pfx -cacerts -nokeys -chain -out ca-chain.pem

Scenario 2: Convert PFX file to PEM format

Execute the following command to convert the data in the certificatepfx.pfx file to PEM format in the convertcert.pem file. The PEM file contains all of the certificates that were in the PFX file, and each of the certificates is wrapped within headers.

Command

openssl pkcs12 -in certificatepfx.pfx -out convertcert.pem -nodes

Snippet of output

Conclusion

In order to use the certificate and private keys on another system in PEM format, you can convert the PFX file using the procedure mentioned above.

Free Downloads

Datasheet of Encryption Consulting Services

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

Download
Encryption Services

About the Author

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

Reading time: 5 minutes

What is SNMP?

The Simple Network Management Protocol (SNMP) is a networking protocol used in Internet Protocol networks to manage and monitor network-connected devices. The SNMP protocol is embedded in various devices such as routers, switches, servers, firewalls, etc., that can be accessed via their IP address. SNMP provides a standard mechanism for network devices to communicate management information within single and multi-vendor LAN or WAN environments. In the OSI model framework, it is an application layer protocol.

There are three versions of SNMP: SNMPv1, SNMPv2c, and SNMPv3. The DSM supports SNMP version 1 or 2.

Components of SNMP

The following are key components of SNMP through with it performs its basic tasks:

SNMP Agent

An SNMP agent is a software process that responds to SNMP queries to provide network node status and statistics. They are located locally and are linked to SNMP network devices from which they collect, store, and transmit monitoring data. When data is queried, it is sent to the designated SNMP manager.

SNMP Manager

It is also referred to as the SNMP server and is responsible for communicating with the SNMP agent-implemented network devices. The manager queries the agents, gets responses from them, sets variables, and acknowledges events from them.

Management information base (MIB)

This exists in the form of a text file (with extension .mib) and describes all data objects used by a specific device that can be queried or controlled using SNMP. Various managed objects within the MIB can be identified using Object Identifiers (Object ID or OID).

Object Identifier (OID)

There are two types of OIDs: Scalar and tabular. These are typically represented as a dotted list of integers. MIBs hierarchically organize every OID, which can be represented in a tree structure with individual variable identifiers for each OID.

SNMP in Vormetric DSM

The Vormetric DSM can be enabled as an SNMP agent and then monitored by SNMP servers using the available MIB objects. When the DSM receives an SNMP GET request (sent to port 7025 or 161) from an SNMP server, the DSM locates the OID entry in the MIB and returns its value to the SNMP server.

SNMP is enabled via the System > SNMP page on the Configuration tab. If the SNMP Access Control List (ACL) is empty, SNMP requests from any IP address will be acknowledged. If the

SNMP ACL is defined to allow only certain IP addresses or IP address blocks to go through; the DSM will only acknowledge requests from IP addresses specified in the SNMP ACL.

The community string is typically set to a factory default value of “public”. This string must be the same for all devices in the same group for SNMP monitoring to function. For security reasons, it is advised to change the community string from “public” to a custom value.

SNMP traps are currently not supported and cannot be configured on the DSM.

The following table represents Vormetric-specific OIDs that can be queried by an SNMP server and are present under the Vormetric MIB tab. These OIDs cannot be manually changed; however, those (sysContact and sysLocation) available under System Group MIB can be customized.

OIDDescription
1.3.6.1.4.1.21513.1.0Returns the version details of the DSM
1.3.6.1.4.1.21513.2.0Returns the fingerprint of the current DSM deployment
1.3.6.1.4.1.21513.3.0Returns the current date and time on the DSM
1.3.6.1.4.1.21513.5.0Returns the agent type (FS, or Key agent), the license installation state (true or false) of each agent type, and, for each installed license, the license expiration date
1.3.6.1.4.1.21513.6.0Returns the name of each node in a DSM HA cluster configuration.
1.3.6.1.4.1.21513.7.0Returns disk usage information for each file system mounted on the DSM.
1.3.6.1.4.1.21513.8.0Return DSMs process, memory, paging, I/O, and CPU usage information

Shell Script

Encryption Consulting recently developed a shell script for one of its customers leveraging the SNMP functionality of Vormetric DSM to automate the process of obtaining insights on the parameters mentioned above. It can be remotely executed from a Linux or Unix host and includes all the commands required to query the DSM using the OIDs provided.

Conclusion

Configuring SNMP in Vormetric DSM can help in its monitoring through an SNMP server. The available OIDs can enable the server to gather information about the DSM with regard to contact information, physical location, version number, fingerprint, server time, license and HA configuration, and disk and system usage information. However, the SNMP functionality must be enabled only with proper security measures, such as by using SNMP ACL to restrict access to the service

Source

Thales Vormetric DSM administration guide

Free Downloads

Datasheet of Encryption Consulting Services

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

Download
Encryption Services

About the Author

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

Read time: 7 minutes

Software development lifecycle (SDLC) is a systematic process for developing software that ensures the quality and correctness of the code. It aims to produce high-quality software within the stipulated time and budget as per customers’ expectations. Each phase of SDLC has its own process and deliverables, which feed into the next phase. Some popular SDLC models include Waterfall, spiral, iterative, agile, etc.

There are only a few SDLC models which explicitly address software security in detail. However, it is necessary to incorporate secure software development practices into each SDLC model. There are various reasons why organizations should plan to implement secure software development practices, which include:

  • To reduce the number of vulnerabilities in released software
  • To minimize the potential impact of the exploitation of undetected vulnerabilities
  • To address the root causes of vulnerabilities to prevent recurrences

Vulnerabilities not only include bugs caused by coding flaws but also weaknesses caused by improper security configuration settings, incorrect trust assumptions, and out-of-date risk analysis.

What is SSDF?

National Institute of Standards and Technology (NIST) has developed a Secure software development Framework, also called SSDF, to strengthen software’s resistance to vulnerabilities. It doesn’t define any new terminologies but consolidates longstanding best-practice recommendations on secure software development. In SSDF, the emphasis is on identifying the best practices rather than on the tools, techniques, and mechanisms used to implement the same.

As per NIST, the SSDF’s practices fall into four major categories:

  1. Prepare the Organization (PO)

    Organizations should ensure that their people, processes, and technology are prepared to perform secure software development at the organization level. Many organizations will also find some PO practices to apply to subsets of their software development, like individual development groups or projects.

  2. Protect the Software (PS)

    Organizations should protect all software components from tampering and unauthorized access.

  3. Produce Well-Secured Software (PW):

    Organizations should produce well-secured software with minimal security vulnerabilities in its releases.

  4. Respond to Vulnerabilities (RV)

    Organizations should identify residual vulnerabilities in their software releases and respond appropriately to address those vulnerabilities and prevent similar ones from occurring in the future.

Each practice definition includes the following elements:

  1. Practice

    The name of the practice and a unique identifier, followed by a brief explanation of what the practice is and why it is beneficial

  2. Tasks

    One or more actions that may be required to carry out a practice

  3. Notional Implementation Examples

    One or more notional examples of types of tools, processes, or other methods that could be used to help implement a task. No examples or combination of examples are required, and the stated examples are not the only feasible options. Some examples may not be applicable to certain organizations and situations.

  4. References

    Pointers to one or more established secure development practice documents and their mappings to a particular task. Not all references will apply to all instances of software development.

NIST recommends weighing risk against cost, feasibility, and applicability when deciding which practices to implement.

The SSDF is not a checklist; rather, it guides you to plan and implement a risk-based approach to secure software development.

Advantages of SSDF:

  1. It can assist organizations in any sector or community, regardless of their size.
  2. It can be applied to software developed to support information technology (IT), industrial control systems (ICS), cyber-physical systems (CPS), or the Internet of Things (IoT)
  3. It can be integrated into any existing software development workflow and automated toolchain; however, it should not have a negative impact on the organizations that already have strong secure software development practices in place.
  4. It makes the practices broadly applicable, rather than being specific to particular technologies, platforms, programming languages, SDLC models, development environments, operating environments, tools, etc.

Conclusion

With NIST architecting SSDF, secure software development is quickly becoming a mandated priority on a large scale. If organizations adopt SSDF, it will help them remain protected from SDLC vulnerabilities and defend their software supply chains.

References

Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities

Free Downloads

Datasheet of Encryption Consulting Services

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

Download
Encryption Services

About the Author

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

Read time: 10 minutes

Quantum computing is a field of study that focuses on the development of computer-based technologies centered around quantum theory principles. To perform specific computational tasks, quantum computing employs a combination of bits. All of this is done at a much higher efficiency than their traditional counterparts. The development of quantum computers represents a significant advancement in computing capability, with massive performance gains for specific use cases.

Quantum bits, or qubits, can be in the state of both 1 and 0 simultaneously, which in turn provides much of the quantum computer’s processing power. Due to this, a fully functioning quantum computer could break the majority of classical encryption algorithms in days, and in some cases even hours.

Quantum-safe cryptography

Post-quantum cryptography, also known as quantum-safe cryptography, refers to research efforts aimed at identifying cryptographic primitives resistant to attacks from classical and quantum computers. The ultimate goal of these efforts is to find cryptographic algorithms that are not vulnerable to any cryptographic attacks by conventional or quantum computers, thereby allowing robust security of information assets in the post-quantum world.

It is widely known that in the absence of quantum-safe cryptography, serious security issues will arise such as transmitted information through public channels could be vulnerable to eavesdropping, and encrypted data could be stored for later decryption considering the power of a quantum computer. Threats arising from quantum computing will target various sectors such as Finance and Healthcare owing to the monetary benefits majorly which can easily be derived from cryptographic vulnerabilities.

The majority of the cryptographic hashes (such as SHA2, SHA3, BLAKE2), MAC algorithms (such as HMAC and CMAK), and key-derivation functions (bcrypt, Scrypt, Argon2) are basically quantum-safe and are slightly affected by quantum computing. Symmetric ciphers such as AES-256 and Twofish-256 are also considered to be quantum-safe. In this case the recommended key length is 256-bits or more.

However, the widely used public-key cryptosystem which includes RSA, DSA, ECDSA, EdDSA, DHKE, ECDH, and ElGamal is quantum-broken.

The following table compares the effective key strength of some popularly used cryptographic algorithms in classical and quantum computers.

Algorithm Key Length Effective key strength
Classical computer Quantum computer
RSA-10241024-bits80-bits0-bits
RSA-20482048-bits112-bits0-bits
ECC-256256-bits128-bits0-bits
ECC-384384-bits256-bits0-bits
AES-128128-bits128-bits64-bits
AES-256256-bits256-bits128-bits

Progress in Quantum-safe cryptography

The possibility of a single quantum-safe algorithm suitable for all applications is quite unlikely. Many algorithms have been proposed till date but there is a large variation observed in the performance characteristics when compared with conventional public key cryptography as quantum safe algorithms use a larger key size therefore require a higher network bandwidth.

The National Institute of Standards and Technology (NIST) has started a process to standardise quantum-safe algorithms for key agreement and digital signatures. Since 2016, the institute has been working on creating quantum-safe algorithms capable of resisting threats posed by the quantum computers. The field of candidate algorithms has been narrowed down and draft standards are expected to roll out in 2022-24.

Migration to quantum-safe cryptography

Transitioning to new cryptography is complicated and will take a significant amount of time and money. Fortunately, organisations have some time before quantum-computers are implemented on a large scale. As per NCSC, ‘Organisations that manage their own cryptographic infrastructure should factor quantum-safe transition into their long-term plans and conduct investigatory work to identify which of their systems will be high priority for transition. Priority systems could be those that process sensitive personal data, or the parts of the public-key infrastructure that have certificate expiry dates far into the future and would be hardest to replace.’Here, crypto-agility might play a key role for organisations in transiting to quantum-safe cryptography as it the ability of a security system to switch between algorithms and cryptographic primitives without impacting the rest of the infrastructure. It is important for corporate leaders to start planning now for a smooth transition to a quantum-resistant security.

Conclusion

We must recognise that quantum computing indeed poses a serious threat to conventional information security systems. Organisations are recommended to plan a robust and secure transition to quantum-safe cryptography to mitigate any quantum threats. It is advisable to follow security best practices until NIST quantum-safe standards are available.

Free Downloads

Datasheet of Encryption Consulting Services

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

Download
Encryption Services

About the Author

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

Let's talk