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

About the Author

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

Search any posts

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

Free Downloads

Datasheet of Encryption Consulting Services

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

Download

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.

About the Author

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

Search any posts

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

Free Downloads

Datasheet of Encryption Consulting Services

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

Download

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

About the Author

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

Search any posts

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

Free Downloads

Datasheet of Encryption Consulting Services

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

Download

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

About the Author

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

Search any posts

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

Free Downloads

Datasheet of Encryption Consulting Services

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

Download

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.

About the Author

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

Search any posts

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

Free Downloads

Datasheet of Encryption Consulting Services

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

Download
ChallengeSolutionBenefits
Inadequate visibility into activity in cloud applications – both sanctioned and unsanctionedGained understanding of both sanctioned and unsanctioned apps, rated them according to customers’ security risk, and selected those that conform to their risk tolerance.Maximises cloud security by monitoring cloud activity.
Inability to enforce security policies on enterprise cloud servicesExtended the reach of customers’ on-prem security policies to the cloud.Ensures compliance and data privacy.
Lack of integration with other security tools and solutionsExtended coverage of on-prem DLP to the cloudIdentifies data loss channels in the organisation.
Inability to identify risky usersHelped organisation in identifying risky user behaviour such as data exfiltration and file oversharingAnalyses and disables accounts indicating malicious activity.
No defined implementation roadmap for CASB technologies.
  • Developed use cases and requirements for CASB solution.
  • Performed vendor analysis.
  • Developed a detailed implementation plan including high-level architectural diagram.
  • Implemented the CASB solution.
Ensures the secure and compliant use of cloud apps and 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.

Search any posts

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

Free Downloads

Datasheet of Encryption Consulting Services

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

Download

Read time: 7 minutes

Before we look at Encryption Backdoor as a whole, let’s have a brief rundown of these two separately. Encryption is a method of scrambling information so only approved keyholders can comprehend the data. In other words, encryption takes decipherable information and adjusts it, so it seems arbitrary.

On the other hand, the backdoor is a means to access a system or encrypted data by avoiding the standard method of authentication. It is typically inserted into a program or algorithm before being widely distributed. It is frequently hidden in the design of the program or algorithm.

What is an Encryption Backdoor?

An encryption backdoor is a method of bypassing authentication and accessing encrypted data in certain services. It can also be defined as a deliberate weakness created by the service provider to allow for easy access to encrypted data. An encryption backdoor would either allow the intruder to guess the access key based on the context of the message or to present a skeleton key that would always grant him access.

Encryption backdoors and vulnerabilities are quite similar theoretically as they both provide an unconventional way for someone to enter a system. However, the difference is that backdoors are created on purpose, whereas vulnerabilities are unintentional.

Benefits of Encryption Backdoors

  1. An encryption backdoor would aid law enforcement and intelligence agencies in their efforts to combat and prevent crime. This would also expedite investigations because agencies would be able to intercept communications and search suspects’ electronic devices to gather data. Officials claim that a backdoor would greatly benefit investigations of terrorism and hate crimes.
  2. It can be used to restore user access when there is no other option. It can also be utilized for troubleshooting purposes.
  3. It can help uncover child sexual abuse material (CSAM) hidden in encrypted messaging applications.

Drawbacks of Encryption Backdoors:

  1. While an encryption backdoor may seem like a boon to solve crimes, it may eventually leave numerous applications and services vulnerable. The same backdoor that the law enforcement agencies and governments are making a strong case for, can be exploited by hackers which would ultimately lead to rise in cybercrime.
  2. Intelligence agencies could misuse a backdoor to spy on people without a warrant and collect maximum data.
  3. IT organizations would be forced to store decryption keys in their databases which would give an opportunity to cybercriminals to steal the keys and extract sensitive information from billions of people.
  4. In the case of IoT devices, the backdoor to one will lead to exposing all other devices connected to the network.
  5. The threats of encryption backdoors increase when enterprises use multiuser and networking operating systems.

Are Encryption Backdoors necessary?

Global tech giants have expressed their displeasure over the inclusion of encryption backdoors. Encryption protects everything from networks and devices to email and banking transactions. Law enforcement agencies might have the best intentions, but it is important to understand that without trusted encryption, the internet would be a more fertile place for hackers.

With privacy experts advising constantly on maintaining the strongest possible encryption standards, and on the other hand, law enforcement agencies willing to have a backdoor in order to nab criminals, clearly shows that no middle ground has been found yet and this debate will only intensify over the time. The only thing we can do presently is protected our data to the best ability.

Conclusion

Encryption backdoors can both be useful and harmful at the same time. At present, there isn’t any well-defined policy for backdoors, however, we hope whatever decision is taken, it’s in the best interest of all, keeping in mind the privacy and data security of citizens as well as the concerns of government apprehending criminals for maintaining public safety.

About the Author

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

Search any posts

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

Free Downloads

Datasheet of Encryption Consulting Services

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

Download

Read time: 10 minutes

Certificate Policy (CP)

A certificate policy describes the measures taken to validate a certificate’s subject prior to certificate issuance and the intended purposes of the certificate. For many organizations, the certificate-issuance policy determines whether the presented certificate will be trusted. The CP also lets users and PKI maintainers know how to apply for a certificate, the naming standards for certificates, and more. The Certificate Practise Statement (CPS) follows the standards set forth in the CP.

Contents of a Certificate Policy

A certificate policy should include the following information:

  1. The method through which user’s identity is validated during certificate enrolment

    The procedure of identifying a genuine user must be defined. It may be via an account and password combination or other different forms of identification which requestors/users must present for validation.

  2. The certificate’s intended purpose

    The purpose for which certificate has been requested must be mentioned clearly in the policy. For e.g. Is the certificate used for authentication on the network or for signing purchase orders? If the certificate is used for signing purchase orders, is there a maximum value allowed? Such questions should be addressed in the certificate policy.

  3. The type of device in which the certificate’s private key is stored

    The private key stored on the computer’s local disk in the user’s profile, or on a hardware device such as a smart card. Other measures, such as implementing strong private key protection or requiring a password to access the private key, can be included in this information.

  4. The subject’s responsibility for the private key associated with the certificate if the private key is compromised or lost

    Is the user responsible for any actions performed using the acquired private key if the private key is compromised or a backup of the private key is lost? This decision can lead to preventing the archival or export of the private key associated with the certificate.

  5. Revocation policies, procedures, and responsibilities

    It consists of the actions or events which will lead to the revocation of a certificate, how the revocation process will be initiated, and who will perform the actual revocation procedure.

Certificate Practice Statement (CPS)

A certification practice statement (CPS) defines the measures taken to secure CA operations and the management of CA-issued certificates. You can consider a CPS to be an agreement between the organization managing the CA and the people relying on the certificates issued by the CA. While the CP tells a user or maintainer what to do, the CPS tells them how to do it.CA’s CPS is a public document that should be readily available to all the participants so that a relying party can determine whether the certificates issued by that CA meet its security requirements or not. The CPS can contain the following information:

  • How the CA will enforce the measures necessary to validate the certificate’s subject, as required by the certificate policy.
  • The liability of the organization if an act of fraud is performed against the service protected by the certificate and the fault is found to be associated with the certificate.
  • The circumstances under which a certificate can be revoked before its expiration.

RFC 3647 recommends a standard CPS format which includes the following nine sections:

  1. Introduction

    The introduction of a CPS provides an overview of the CA, as well as the types of users, computers, network devices, or services that will receive certificates. It also includes information on certificate usage.

  2. Publication and Repository Responsibilities

    This section contains details regarding who operates the components of the public key infrastructure and the responsibilities for publishing the CP or CPS.

  3. Identification and Authentication (I&A)

    This section describes the name formats assigned and used in certificates issued by the CA. It also describes the certificate policy and assurance levels implemented at the CA and details identification procedures for.

  4. Initial registration for a certificate

    The measures taken to validate the identity of the certificate requestor.

  5. Renewal of a certificate

    Are the measures used for initial registration repeated when a certificate is renewed? In some cases, possession of an existing certificate and private key is sufficient proof of identity to receive a new certificate at renewal time.

  6. Requests for revocation

    When a certificate must be revoked, what measures will be taken to ensure that the requestor is authorized to request revocation of a certificate?

  7. Certificate Life-Cycle Operational Requirements

    This section defines the operating procedures for CA management, issuance of certificates, and management of issued certificates.

  8. Facility, Management, and Operational Controls

    It describes physical, procedural, and personnel controls implemented at the CA for key generation, subject authentication, certificate issuance, certificate revocation, auditing, and archiving. These controls can range from limiting which personnel can physically access the CA to ensuring that an employee is assigned only a single PKI management role

  9. Technical Security Controls

    This contains the security measures taken by the CA to protect its cryptographic keys and activation data.

  10. Certificate, CRL, and OCSP Profiles

    It is used to specify three types of information:

    • Information about the types of certificates issued by the CA For example, are CA issued certificates for user authentication, EFS, or code signing?
    • Information about CRL contents This should provide information about the version numbers supported for CRLs and what extensions are populated in the CRL objects.
    • OCSP profiles This section should provide information on what versions of Online Certificate Status Protocol (OCSP) are used (for example, what RFCs are supported by the OCSP implementation) and what OCSP extensions are populated in issued certificates.
  11. Compliance Audit and Other Assessment

    The section details what is checked during a compliance audit, how often the compliance audit must be performed, who will perform the audit (is the audit performed by internal team or by a third party?), what actions must be taken if the CA fails the audit, and who is allowed to inspect the final audit report.

  12. Other Business and Legal Matters

    It specifies general business and legal matters regarding the CP and CPS. The business matters include fees for services and the financial responsibilities of the participants in the PKI. The legal matters include privacy of personal information recorded by the PKI, intellectual property rights, warranties, disclaimers, limitations on liabilities, and indemnities.

Conclusion

The Certificate Policy is a document which defines standards of the PKI, and the Certificate Practice Statement sets forth the procedures used in the PKI.

About the Author

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

Search any posts

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

Free Downloads

Datasheet of Encryption Consulting Services

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

Download

Read time: 10 minutes

Rivest Shamir Adleman (RSA) is an asymmetric algorithm that can be used for encrypting and signing data. The encryption and signing processes are performed through a series of modular multiplications. The security of the RSA algorithm can be increased by using longer key lengths, such as 1,024 bits or more—the longer the key length, however, the slower the encryption or signing process. It is one of the most popular and secure public-key encryption methods. There are two different RSA signature schemes specified in the PKCS1

  • RSASSA-PKCS1-v1_5: old Signature Scheme with Appendix as first standardized in version 1.5 of PKCS #1.
  • RSASSA-PSS (RSASSA = RSA Signature Scheme with Appendix): based on the Probabilistic Signature Scheme (PSS) originally invented by Bellare and Rogaway.

Difference between RSASSA-PKCS1-v1_5 and RSASSA-PSS:

RSASSA-PKCS1-v1_5RSASSA-PSS
PKCSV1_5 is deterministicIt is randomized thereby producing a different value of signature each time
Message digest value can be extracted from a PKCSV1_5 signatureIt cannot be extracted from a PSS signature but can only be verified against a known message digest value
Less secure and robustPSS has security proof and is more robust than PKCSV1_5
It’s an old schemeIt’s a new scheme
It is recommended for compatibility with the existing signature applicationIt is recommended for compatibility with existing signature applications It is recommended for eventual adoption in new signature applications as it does not contain certain critical points of the older standard

Attacks on old signature schemes

  1. The Bleichenbacher attack

    In 1998, Daniel Bleichenbacher found out that the messages returned by SSL servers for errors in Public-Key Cryptography Standards (PKCS) #1 version 1.5 padding enabled an adaptive-chosen ciphertext attack, in which an attacker sends a series of ciphertexts to be decrypted, and then uses the results of these decryptions to select subsequent ciphertexts. This allowed an attacker to perform RSA decryption and signing operations using the private key of a TLS server, completely breaking the confidentiality of TLS when used with RSA encryption.

  2. Fault-based attack

    In 1996, Dan Boneh and others presented an attack on RSA doing faulty calculations. By injecting random faults into the calculations of RSA, they were able to regenerate the private key from the knowledge of the faulty signatures. RSA implementations using the Chinese remainder theorem to speed up calculations are especially vulnerable – a single erroneous signature allows the regeneration of the private key.

    Protection against fault-based attacks like this is especially important in embedded devices like chip cards that are built not to expose the private key, but to provide cryptographic operations like signatures in an environment potentially under the control of an attacker. But in further studies, it has been established that PSS is not vulnerable to these fault-based attacks.

RSASSA-PSS

RSASSA-PSS is an improved probabilistic signature scheme with an appendix. This means that a private RSA key can be used to sign the data in combination with random input. The other side of the communication can then verify the signature using the corresponding public RSA key. This signature scheme uses random data, so two signatures with the same input are different and both can be used to validate the original data.

RSASSA-PSS Parameters

  1. Hash Algorithm/Function

    Hash functions are used in encryption schemes, signature schemes with appendix and various encoding methods. Hash functions are deterministic, meaning that the output is completely determined by the input. Hash functions take input strings of variable length and generate fixed length output strings.

  2. Mask Generation functions

    A mask generation function takes an octet string of variable length and the desired output length as input and outputs an octet string of the desired length. Mask generation functions (MGF) are deterministic in nature. The output of a mask generation function should be pseudorandom, that is, if the seed to the function is unknown, it should be infeasible to distinguish the output from a truly random string.

    The provable security of RSAES-OAEP and RSASSA-PSS relies on the random nature of the output of the mask generation function, which in turn relies on the random nature of the underlying hash.

  3. Salt length

    It is the salt value associated with the signature operation. The field is intended to facilitate single-pass processing. If the field is omitted, the salt value shall be obtained from the signature. The salt value enhances the security of the scheme by affording a “tighter” security proof than deterministic alternatives such as Full Domain Hashing (FDH)

  4. Trailer field

    It is used in the encoding operation and is an integer. The value MUST be 1, which represents the trailer field with hexadecimal value 0xBC.

Default Parameters

hashAlgorithm

Default value is SHA1, however SHA-256 is recommended

maskGenAlgorithm

MGF1 needs to be used. mgf1SHA1 (the function MGF1 with SHA-1)

saltLength

The default value is 20 but the convention is to use hLen, the length of the output of the hash function in bytes.

trailerField

trailerFieldBC (the byte 0xbc)

It is recommended that the MGF hash function be similar to that of scheme hash algorithm/function, and that the salt length be hLen which is the length of the output of the hash function.

Conclusion

RSASSA-PSS is an improved signature scheme which contains an attachment. It uses an RSA private key to sign the data and thereafter, the recipient can verify this signature using the public RSA key. It has various parameters and is more secure and robust as compared to others.

About the Author

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

Search any posts

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

Free Downloads

Datasheet of Encryption Consulting Services

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

Download

Read time: 10 minutes

This is a location in the form of URLs where the issuing CA’s base certificate revocation list (CRL) is published. If revocation checking is enabled, an application will use the URL to retrieve an updated version of the CRL. URLs can use Hypertext Transfer Protocol (HTTP), LDAP, or File.

Importance

With the help of CDP, an application or a site-visitor can retrieve the Certificate Revocation List (CRL) thereby determining whether the digital certificate is trustworthy or not. This can protect them from visiting or accessing fraudulent sites and from man-in-the-middle attacks. In the absence of CRL, they might be vulnerable to data-theft, malware, fraud, financial loss etc.

Defining CRL Distribution Points:

You can define a CA’s CDP URLs by using the certutil command to edit the CRLPublicationURLs registry entry. The command allows you to designate one or more URLs as well as which CRL publication options are enabled for each URL.

For example, consider the following certutil command that defines the CDP extension:

certutil -setreg CACRLPublicationURLs “1:C:Windowssystem32CertSrvCertEnroll%3%8%9.crln10:ldap:///CN=%7%8,CN=%2, CN=CDP,CN=Public Key Services,CN=Services, %6%10n2:http://pki.EncryptionConsulting.com/CertEnroll/%3%8%9.crl”

This command defines three separate URLs. The URL order is important when implementing
Windows clients because it specifies the order in which the certificate chaining engine searches URLs when retrieving an updated CRL version. Likewise, the number that precedes each URL represents the enabled options for each URL.

1:C:Windowssystem32CertSrvCertEnroll%3%8%9.crl : This URL ensures that
the CRL file is copied to the local file system every time the CRL is automatically or manually published.

10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10 : This URL enables two values: 2 to designate the CRL’s publication point in AD DS and 8 to include the CDP URL in all CA-issued certificates.

2:http://pki.EncryptionConsulting.com/CertEnroll/%3%8%9.crl : This URL ensures that
the URL pki.EncryptionConsulting.com/CertEnroll/%3%8%9.crl is included in the CDP extension of all issued certificates.

CDP variables

Variable Name Description
%1 ServerDNSName The CA computer’s Domain Name System (DNS) name
%2 ServerShortName The CA computer’s NetBIOS name
%3 CA Name The CA’s logical name
%6 ConfigDN The Lightweight Directory Access Protocol (LDAP) path of the forest’s configuration naming context for the forest
%8 CRLNameSuffix The CRL’s renewal extension
%9 DeltaCRLAllowed Indicates whether delta CRLs are supported by the CA
%10 CDPObjectClass Indicates that the object is a CDP object in AD DS

CRL Publication options

Variable Name Description
%1 ServerDNSName The CA computer’s Domain Name System (DNS) name
%2 ServerShortName The CA computer’s NetBIOS name
%3 CA Name The CA’s logical name
%6 ConfigDN The Lightweight Directory Access Protocol (LDAP) path of the forest’s configuration naming context for the forest
%8 CRLNameSuffix The CRL’s renewal extension
%9 DeltaCRLAllowed Indicates whether delta CRLs are supported by the CA
%10 CDPObjectClass Indicates that the object is a CDP object in AD DS

How to add a CDP

Command:

Add-CRLDistributionPoint [-InputObject] <CRLDistributionPoint[]> [-URI] <String[]> [<CommonParameters>]

Parameters:

-InputObject <CRLDistributionPoint[]>  -> Specifies the CRLDistributionPoint object to which new CRL distribution points are added

[-URI] <String[]>  -> This specifies new CRL file publishing distribution points for a particular CA.

<CommonParameters> : The cmdlet supports common parameters like: Debug (db), ErrorAction (ea), ErrorVariable (ev), InformationAction (infa), InformationVariable (iv), OutVariable (ov), OutBuffer (ob), PipelineVariable (pv), Verbose (vb), WarningAction (wa), WarningVariable (wv)

Conclusion:

The CRL distribution points (CDP) is a X.509 version 3 certificate extension which identifies the location of the Certificate Revocation List (CRL) from which the revocation of the requested certificate can be checked.

The application that processes the certificate can get the location of the CRL from this extension, download the CRL and thereafter validate the revocation status of the requested certificate.

About the Author

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

Search any posts

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

Free Downloads

Datasheet of Encryption Consulting Services

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

Download

Let's talk