Setting up Audit is one of the key aspects of any security architecture. For ADCS, logging is important as well. You may enable and set up Active Directory Certificate Services auditing using the instructions given in this article.
First thing First!
The first step is to ensure that auditing is enabled on your ADCS servers.
For this, Run the auditpol command and make sure “Registry” and “Certificate Services” advanced auditing are turned on.
Wait, but what is auditpol?
Windows captures logs of all kinds which may not be useful to us and cause a lot of confusion and loss of focus. To address this, Microsoft has introduced auditpol. Auditpol is used to categorize granually these logs at user level.
Remember to refresh the group policy after you have enabled it!
Some more examples to use auditpol are shown below :
Example 1:
Example 2 :
In our ADCS use case we will use:
auditpol /get /category:*
The next step is to enable monitoringusing the ADCS snap-in.
To do this, performthefollowing steps on the ADCS server.
Open Server Manager Select Tools -> Certificate Authority Right-click the CA name and selectProperties. Select monitor Enable requiredmonitoring settings Backing up and restoring the CA database Change CA configuration Change CA security settings Issuing and managing certificate requests Revoke certificates and publish CRLs Storing and retrieving archived keys Starting and stoppingthe ADCS
The next step is to enable the certificate template changes using the certutil command.
Some changes can be made directly through the registry, so registry auditing should be enabled. For this you need to:
Open regedit on the ADCS server Findbelow RegistryKey HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\ Rightclickon Configuration and select Permissions Click Details SelectMonitoring and click Add Set the principal to Authenticated Users and configure the following permissions: setvalue createsubkey fireextinguishing write DAC writeowner readcontrol
Restart the server and see your changes. After rebooting, you will see various event IDs in the security log.
Reboot your server and verify the changes. After the reboot, you should see different event IDs in your Security logs.
Now we have the ADCS auditing up and running.
You can also sieve the audit logs via Azure Arc and Azure Sentinel as well using “Data Collector Rules” in MS Azure.
In the recent past, many technology firms are being targeted by hackers to tamper and corrupt the source code. These attacks heavily impact brand reputation and also leads to huge losses for firms victimized. To tackle this scenario, Code Signing technique can be used for safe guarding the code integrity and to provide authenticity of the author to the end user by providing digital signatures. Code Signing provides secure and trusted distribution of software preventing tampering, corruption and forgery. Code signing improves end-user confidence in software/code integrity and sender authenticity.
Code Signing Architecture provides a detailed explanation on how the Code Signing process works along with its components. Mentioned below are the four important differentiating components in the Code Signing Architecture.
These four components together will achieve the full cycle completion of the code signing process. Each component has a defined working process which is discussed in detailed below.
Code Signing System (CSS):
The Code Signing System (CSS) is the first and important component of Code Signing Architecture. Code signing system signs the submitted code using digital signature and authenticates the author. The digital signature is generated by CSS using private signing key and certificates. It is highly important to secure the private signing key and certificate from misuse and unauthorized access.
Certificate Authority (CA):
Developers or Source issuing code should use certificates from authentic certificate authorities (CA) as the certificate enables the process of authenticating the source. Certificates issued by authentic certificate authorities must comply with standard certificate policies such as NIST Interagency Report 7924 which specifies requirements to be followed by CAs while issuing certificates. Also, the developer requesting the certificate from authentic CAs has to provide supporting validation documents which would be verified before providing certificates. CA would follow guidelines mandated by standard agencies such as CA security council, CA/Browser Forum etc.
Time Stamp Authority (TSA)
An optional but important component in Code Signing Architecture is Time Stamp Authority (TSA). Time stamping preserves the source time when the code was signed and allows software to be accepted by the OS and other client device platforms even after the certificate expires. Signed software is validated with the source time when the certificate was signed rather than the current time. Hence, it is always advisable to use Time stamping technique while performing code signing. Digital signature signed code is sent to TSA for time stamping. TSA applies its own signature along with the valid source time stamp. TSA is independent from Code Signing System and synchronizes its clock with an authoritative time source.
Verifiers
End user using the code digitally signed by the publisher first initiates the process of verifying the signature. In general, verifiers are used to perform this step of validating the signatures and time stamp (if any). Verifiers leverage trust anchors to validate the signature on the signed code. Trust anchors are usually public keys of root certificate authorities (CA) installed securely on the verifying platform. In general, root CAs use standard architecture such as X.509 standard. If your organization is looking for implementation of Code signing, please consult info@encryptionconsulting.com for further information
Code Signing, as a technology, provides authenticity to the software codes, applications and/or files. This is done by signing the code using digital certificates and public key infrastructure. Hence, code signing provides assurance and trust to end users against code tampering or corruption. This is just one of the benefit of using code signing. To explore the “Top 5 benefits of Code Signing“, please go through the blog article: www.encryptionconsulting.com/code-signing-top-5-benefits
Every organization is expected to benefit a lot through code signing and this very reason makes this technology critical. One has to keep in mind the best practices to be followed while implementing code signing. Because when there is a breach of private keys of your company due to poorly implemented infrastructure, it not only impacts the customers but also the trust they have on your brand and its products.
Let’s take a look into the most critical best practices your company has to follow while implementing code signing technology:
Code Signing: Best Practices :
Separation of environments: Test signing and Release signingOne of the important code signing best practice is to set up a parallel environment for code signing infrastructure to sign test code with an internal test root Certificate Authority (CA). Internal test root CA would provide test certificates for signing the code. This benefits the firm in two ways, first benefit is limiting the exposure of actual private keys and code signing mechanisms to close group of users/developers and the other benefit is to opportunity to test the signed code for functionality bugs and vulnerabilities.
Test signing can be done in two ways:
Test Certificate Signing Authority
Self-signed certificates
Mid-size to small sized organizations can use self-signing certificates for the test code sign process. This might involve some effort to make the certificates trusted as, by default, it won’t be trusted. In general, one can obtain these certificates through free tools without using any public key infrastructure (PKI). Organizations with complex and huge size test environment can use internal test CA for generating test certificates for the code signing process.
Either your firm uses self-signed certificates or internal test CA, always ensure that code signing process and root certificates are separated between test and production environment.
Restricted access to Private keys through physical securitySystems with private keys have to have minimal access. As the saying goes, the most secure computer would be the one with minimum external connections. Hence, minimize the number of personnel having access to system with private keys used for code signing process.
Physical security is equally important for securing the sensitive data. In spite of all the virtual measures taken, if there is an employee or contractor who gains unwanted access can be a high threat. Physical measures such as cameras, fingerprint access, security guards etc. can be utilized for providing physical security.
Cryptographic hardware protection modules (HSMs)Cryptographic hardware protection modules restrict the export of private keys from these devices. Cryptographic modules are tamper proof and secure for storing keys that are used to sign digital certificates. There are three important types of cryptographic devices used for securing keys:
In general, HSMs are preferred over other devices as the security standards are relatively higher. Ensure that all the devices used are compliant with FIPS 140 level 2 certified.
Timestamp process: Public or PrivateTime stamping process helps in verifying the authenticity of the publisher after the expiry of certificate. Public time stamping authority can be used for cost benefit but it is always suggested to use internal timestamp authority to avoid public network access.
Timestamp certificates can be issued for a maximum time period of 135 months. Strict measures has to be taken while you expose code signing process during external/public time stamping.
Scan the code for viruses Code signing process helps in authenticating the code alone and cannot secure the code. Hence, it is always suggested to perform virus and malware scans before publishing the code and signing with digital certificates. Using virus/malware scan improves the quality of code as well.
If your organization is looking for implementation of Code signing, please consult info@encryptionconsulting.com for further information
If you are a CISO or holding an equivalent position for any organization, one of the biggest nightmares would be failure of line of defense for data security. One such important module relevant to data protection is “Code Signing”. Organizations have to be aware of threats posed to Code signing process and implement reasonable recommendations for tackling the issues.
According to a study conducted by Venafi, it is understood that out of 320 participants from USA, Europe and Canada more than 28% implement a defined code signing policy for protecting certificates used for signing code. There are high chances of forging and stealing of certificates by cyber hackers when proper policies are not enforced for code signing.
Let’s discuss few scenarios of threat landscape for “Code Signing” when appropriate code signing policy is not in place.
Potential Threats to Code Signing
Theft/Loss of Private Signing KeysPrivate signing keys have to be protected with utmost care. Many incidents are reported regularly due to theft of private signing keys. Cyber criminals with access to these signing keys might masquerade malware/malicious code as an authentic code or software. These incidents would cause huge financial loss as well as brand reputation loss. A single compromised private key can cause devastation to the entire firm’s business.
Real world incidents due to theft of private signing keys caused lot of damage for the affected firms. Governments also are affected by the loss of private keys and one of the classic examples is the attack on Malaysian Government during November 2011 where legitimate certificates stolen were used to sign malware.
Compromised Certificate AuthorityDirect attack launched on certificate authority (CA) issuing code signing certificates can cause severe damage to the firm using the certificates. Hence, it is always advisable to ensure the best practices are followed by CAs issuing certificates. Cyber attack incidents on CAs can even lead to the bankruptcy of the firm issuing certificates.
One such incident happened to a Dutch certificate authority – DigiNotar in 2011. Certificate Authority was compromised by hackers and issued fake certificates for many reputed websites which eventually resulted in bankruptcy of DigiNotar.
Best practice is to perform assessment on the vetting processes used by Certificate authority and data security measures in place before choosing the CA.
Use of insecure cryptography governance controls:Usage of weak and insecure cryptographic algorithms for code signing process would create vulnerabilities which can lead to cyber attacks such as brute force attack to hack keys used for code signing. Poor governance controls can cause intrusions into development and production systems. These security lapses can cause malicious code to be signed and authenticated.
CISOs should consider implementing proper governance controls to create secure environment. Also, performing appropriate assessment of code signing processes would avoid any unprecedented breach.
Venafi research survey on Code signing best practices and processes followed across US, Canada and Europe showed an astonishing picture about code signing landscape. More than 50% of the respondents across US, Canada and Europe either do not have code signing processes defined or implementing informal process with inconsistency. This is a huge alarming concern for CISOs.
35% of the respondents do not have clear owner for managing code signing private keys. In many cases, either development team or information security or both are managing private keys used for code signing.
It is the responsibility of CISOs to consider hiring an in-house team or a consulting firm who possess expertise in cryptography and code signing processes for better and secure implementation of “Code Signing”.
If your organization is looking for assessment and/or implementation of Code signing, please consult info@encryptionconsulting.com for further information
Code signing is the process of authenticating software code/application/program/scripts to confirm the source of origin of the publisher and assure that the code has not been tampered or altered since it was signed.
Certificate Authorities (CA) confirm code signing source identity and bind their public key to a code signing certificate. This certificate enables validation of code sign with an authentic root certificate. Performing code sign will cater below three functions:
Provides authentication of code
Provides cryptographic protection
Software/code author validation
Top 5 benefits of “Code Signing”:
Let us take a look into the top 5 benefits users can enjoy by using “Code signing”:
Validates code integrity: Code signing provides integrity check of the code using hash function. Hash function is used at the source to sign the code and the same hash has to be matched at the destination. This provides proof of code integrity. If the hash is not matched, users would either receive a security warning or code will fail to download.
Verification can be performed using timestamp as well. Code signing certificates might include optional time stamp. Time stamp data strip is included along with signature during the time of signature. This process ensures the validity of certificate at the time of signature.
Issuing company reputation and authenticity:Using code signing process for authentication and validation of software, code and/or programs eliminates the risk of program corruption and tampering. This will safeguard the company’s reputation as well as intellectual property.
Enhancing trust on both sides of the transaction, companies can be more benefitted with customers trusting their software programs, files etc. for download. With increase in reputation one can expect considerable increase in customer loyalty.
Increase in revenue:Now a days, software publishers and network platform provides are increasingly mandating code signing process from a trusted source/certificate authority (CA) for distribution of software among users.
This is even more beneficial for small companies or individual developers to gain trust among customers through authenticity and increase their brand presence as well as revenue.
Safe and secure user experience:As already discussed in one of the points mentioned above, Code signing process builds mutual trust amongst both the parties i.e. vendor as well as consumer. On top of it, customers who use code signed software or files can be sure of security as the code is properly authenticated and validated which prevents code tampering.
Also, using code signing provides smooth user experience as there will be minimized security warnings and installation failures when code is signed by trusted certificate authority.
Seamless integration with multiple platforms:Code signing process is now available on multiple platforms such as Apple iOS, Windows, Linux, Android, JAVA, Adobe AIR etc. Many of these platforms highly recommend code signing process for code distribution.
Many browsers would require code signed using certificate from trusted certificate authority and reject any action commands provided through untrusted sources. One interesting fact is, Microsoft office macros and Firefox browser extensions also require code signing.
If your organization is looking for implementation of Code signing, please consult info@encryptionconsulting.com for further information
When downloading software from the Internet, consumers must always be wary of 3rd parties masquerading as the software provider. With a resource like code signing, software can be assured it is coming from the proper source. Code signing is an operation where a software developer or distributor digitally signs the file being sent out, to assure users that they are receiving software that does what the creator says it will. The signature acts as proof the code has not been tampered with or modified from its original form.
With the ability to download so much software from the Internet, code signing has become more and more important for software developers and distributors to use. An attacker can easily mask themselves as a legitimate source to plant malware on a victim’s computer. Code signing assures these types of attacks cannot occur, as long as users only download software deemed safe by their operating system. Nowadays, when software is downloaded onto a computer, the Operating System checks for the digital certificate created through code signing, to assure the safety of the software attempting to be installed. If no digital certificate is found, then the user is alerted to this fact, and prompted to either stop or continue the installation.
How Does Code Signing Work?
Code signing has several steps, beginning with the creation of a unique key pair. The key pair created is a public-private key pair, since code signing utilizes public key cryptography. Once the key pair is created, the public key is sent to a trusted certificate authority, or CA, which verifies that the key belongs to the owner by returning the public key to the software developer, along with a digitally signed code signing certificate. A CA is a highly trusted entity given the responsibility of signing and generating digital certificates. The certificate, with the attached public key, returned by the CA confirms the trustworthiness of the developer and any software they create.
Now that the public key and a digital code signing certificate have been returned, the code of the software is run through a hash function. A hash function is a one-way function that turns the text put into the function into an arbitrary mixture of values that cannot be reversed. This provides a value to compare with when the data is sent to the consumer. The output, or digest, is then encrypted by the private key. The reason the private key is used for encryption, as opposed to the public key, is because the developer wants anyone to be able to read the message, but no one to be able to tamper with it. The digest, code signing certificate, and hash function are now combined into a signature block and placed into the software, which is sent to the consumer.
When the software is received, the consumer’s computer first checks the authenticity of the code signing certificate. Once the authenticity is confirmed, the digest is then decrypted with the public key of the originally created key pair. The hash function is then used on the software’s code, and the resulting digest is compared to the digest sent by the developer. If the digests match, then the software is safe to install.
Advantages of Code Signing
Code signing provides many benefits, including the ones listed below.
With code signing, users can trust the software they are downloading, and need not worry about downloading malware onto their computer or mobile device. This authentication acts as a two-way street, with code signing promoting trust on both sides of the exchange. Not only can the user trust the sender, but the developer can also trust their software got to the correct location and is not being misused.
Since many of the biggest trusted mobile and web application stores, such as the IOS AppStore or Google’s Play Store, require code signing, developers can distribute their software through even more platforms.
Weaknesses of Code Signing
There are several weaknesses to code signing, as well, including:
Improper management of the private key created at the beginning of the code signing process can result in the insecurity of the software being sent. If a legitimate private key is stolen, then the attacker can encode their malicious software with the private key, which will tell the user that the software is safe to use, even if it isn’t.
Threat actors can obtain a trusted certificate, but what deters most attackers is the need to provide identification information to obtain a certificate. If malicious software is distributed with a legitimate certificate, the developer can be identified and stopped.
If the user allows the installation of the software, even if the Operating System says it is not code-signed, then code signing is rendered useless.
To prevent these weaknesses, there are best practices that should be followed.
For the protection of encryption keys, Hardware Security Modules, or HSMs, should be used. An HSM is a specialized, highly trusted physical device. It is a network computer which performs all the major cryptographic operations including encryption, decryption, authentication, key management, key exchange, etc. They are tamper-resistant and use extremely secure cryptographic operations.
Along with HSMs, the principle of least privilege should be used with keys, to ensure only users who need the key have access to it.
Finally, caution should always be used with code signing. Only download and install software that is code signed by a trusted CA.
Who Uses Code Signing?
Code signing is used in any commercially packaged and distributed software. Trusted application stores, like the IOS AppStore or the Google Play Store, require code signing for a piece of software to be distributed on their platform. A lot of consumers will not download software unless it uses code signing, so even developers that aren’t on big-name platforms will implement code signing. There are several different types of certificates to use, dependent on what systems the software being distributed works with. Desktop certificates include Microsoft, Java, Microsoft Office, and VBA, and Adobe AI. Examples of mobile certificates are Windows Phone, Windows Phone Private Enterprise, Java Verified, Android, and Brew.
Some examples of code-signed software are Windows applications, Windows software updates, Apple software, Microsoft Office VBA objects and macros, .jar, .air, and .airi files, and any type of executable file. For IOS applications, code signing uses Xcode. To upload software to the Itunes store, the user must have a valid Apple Developer ID with a valid certificate or profile before Xcode will sign the software. To integrate an application, the developer will need to use a development certificate. In order to run the app on any device, a distribution certificate must be used to send out the app and test it. Other platforms, like Windows, just require the use of a trusted certificate authority. C# and Visual Studio also offer their own code signing solutions. Encryption Consulting provides its own code signing solution called CodeSign Secure.
Code Signing Solution – CodeSign Secure
CodeSign Secure provides a secure and flexible solution for implementing code signing on in an on-premises, Cloud, or hybrid environment. Security keys can be created or imported into HSMs, such as the AWS Cloud, Azure Key Vault, Mac Key Chain/ Secure Enclave, Thales, Utimaco, or nCipher HSM. Securing cryptographic keys within an HSM eliminates the risks associated with stolen, corrupted or misused keys. CodeSign Secure is available on Windows, Linux, or Macintosh systems, and seamlessly integrates with your existing build processes. Windows files like .exe, .dll, .msi, .cab, and .ocx, RPM files on Linux, jar files, Mac OS software, Andorid apps, iOS apps, PDF files, and Docker images can all be signed by CodeSign Secure, ensuring their safety and originality to the end user. CodeSign Secure includes fully automated and customizable approval workflows, and automated malware and virus scans using your preferred scanners.
Our service integrates with Corporate Active Directory and provides complete audit trails and reports available at all times. Multi-factor authentication can also be enabled with CodeSign Secure. The robust access control system which can be integrated with LDAP and customizable workflows mitigates risks associated with granting wrong access to unauthorized users, allowing them to sign code with malicious certificates. The open architecture framework of CodeSign Secure provides the utmost flexibility in integrating with a user’s environment, without altering their existing build processes, be it traditional SDLC, Agile or DevOps. The On-Premises model of CodeSign Secure has the server and client modules installed locally, and integrates with any existing HSM, for easy and swift access to keys. The Cloud model has the organizations subscribe to CodeSign Secure services online. The hybrid model has server and client modules installed locally within the customer premise, while the private keys for signing certificates can be stored on cloud HSM and vice-versa.
Code Signing is the process of applying a digital signature to a software program intended for distribution over the internet. Code signing helps to verify that the software is authentic i.e. from the original developer, and also helps to validate that the code has not been tampered with by an attacker while in transit e.g. by the insertion of malicious code or malware. The digital signature used for code signing is contained in a digital certificate called the code signing certificate.
Code Signing Certificates
Like any other digital certificate, code signing certificates are based on the X.509 standard and also need to be signed by a trusted third party such as a Certificate Authority (CA). However, code signing certificates cannot be used interchangeably with other certificates such as SSL certificates. The main reason for this is that as per the X.509 specification, any digital certificate contains a “Key Usage” field, which indicates the intended use of the certificate and is filled in at the time the certificate is generated. Additional information regarding the use of the certificate can also be contained in the “Extended Key Usage” extension. The X.509 specification mandates that a certificate cannot be used other than for it’s intended purpose. For example, an SSL certificate has the key usage field set to “Digital Signature” whereas a code signing certificate has the key usage field set to “Code Signing”.
While X.509 provides the specification for the certificate format, the technology implementations to generating certificates will vary by vendor. For example, Authenticode is code signing technology from Microsoft that helps developers sign applications for the Windows operating system. Authenticode certificates are used to sign files with extensions such as .exe, .dll, .ocx, .cab, and .xpi. Similarly, Apple code signing certificates are used to sign applications for iOS, Java code signing certificates are used to sign .jar files for the Java Runtime Environment (JRE), and Adobe AIR certificates are used to sign .air or .airi files.
The process of obtaining a code signing certificate is similar to other digital certificates. Any organization that wishes to publish software for distribution over the internet applies for a code signing certificate with a CA, submitting their public key and other organization information. Note that the public-private keypair needs to be separately generated, like in the case of any digital certificate. The CA validates the developer (organization) applying for the certificate, signs the certificate as proof of validation, and issues the same to the developer or software publisher. The certificate that the CA issues includes information such as the publisher identity, the public key of the publisher, the certificate validity period, the digital signature of the CA, and other details.
Types of code signing certificates
Self-signed certificates: It is possible for software publishers to generate their own self-signed certificates. In such cases however, the signature verification process during software installation will generate a warning that the software was created by an unknown publisher. Self-signed certificates could be used for testing and local development of software, before it is made generally available for public distribution. However, self-signed certificates should not be used for production software being distributed to end users.
For public software distribution, CA issued certificates are the best option. There are two types of CA-issued code signing certificates based on the type of validation.
Standard Validation Certificates: This is the default type of code signing certificate and involves basic validations of the publisher or developer by the CA. To be issued a standard code signing certificate, software publishers need to meet some basic requirements such as minimum key length, maximum validity period, and time stamping for digital signatures.
Extended Validation (EV) Certificates: EV code signing certificates involve the highest levels of validations and vetting of the software publisher by the CA and are usually issued on a hardware token for additional levels of security. To be issued an EV certificate, apart from the basic requirements of standard certificates, software publishers also need to conform to much more stringent requirements – for example maintaining private keys in a Hardware Security Module (HSM) that is compliant with FIPS (Federal Information Processing Standards) 140 Level-2 or equivalent.
Certificate Expiry and Time Stamping
Like any digital certificate, code signing certificates also expire at the end of their validity period. On expiry, the signature will not be validated, and the software may cease to install or execute properly, although nothing is wrong with the software itself. This issue is addressed by the process of time stamping, in which a time stamp is applied to the code at the time of signing the file. This is usually done through another trusted third party called a Time Stamp Authority (TSA), to prove the validity and authenticity of the time stamp. The presence of a time stamp ensures that the software continues to run even though the code signing certificate has expired, giving the publisher time to renew the certificate.
Certificate Revocation
We have seen in earlier articles that the strength of Public Key Infrastructure (PKI) systems depends on how the private keys are managed and secured. If the private key for any digital certificate is compromised, the certificate needs to be invalidated, or revoked by the CA which issued the certificate. Certificate revocation is critical in the event of a breach: it ensures that end users are alerted that the certificate can no longer be trusted, discouraging the download, installation and further usage of the software. Certificate revocation is done by including the revoked certificate in a Certificate Revocation List (CRL), or by updating the certificate status using the Online Certificate Status Protocol (OCSP). Further details about CRLs and OCSP will be covered in a later article.
Public Key Infrastructure (PKI) is based on the principles of asymmetric cryptography: messages are encoded using the recipient’s public key, and the recipient decodes the message using her private key. However, how do we know that the public key we are using indeed belongs to the intended recipient? What if the public key is a forgery and belongs to an impersonator? A digital certificate helps to establish whether a public key truly belongs to the purported owner. Just like a physical certificate of identification such as a driver’s license or a passport, a digital certificate provides information about an individual along with her/his public key and helps anybody else verify the identity of that individual. The certificate also contains one or more digital signatures, which indicate that the information in the certificate has been attested by some other trustworthy person or entity, known as a certificate authority. We will cover more about certificate authorities in a subsequent article.
Types of digital certificates
The main types of digital certificates that are used today are:
Server certificates: These implement the SSL/TLS (Secure Sockets Layer / Transport Layer Security) standards, are installed on the server, and are best known to have enabled the boom in e-commerce implementations by helping secure the communication channel between the client and server. SSL certificates in turn are of three types:
Domain Validation (DV) certificates: These only verify that the certificate owner has the right to use the domain name; however, they don’t certify who the owner is. Since they involve only basic validation, they are cheap and can be obtained instantly from the certificate provider. DV certificates are typically used for basic web sites and web applications.
Organization Validation (OV) certificates: These provide additional assurances about the certificate holder and include validations about the organization, domain ownership, and whether the applicant is authorized to apply for the certificate. OV certificates are a good option for e-commerce web sites.
Extended Validation (EV) certificates:These offer the highest levels of encryption and follow a strict authentication process before the certificate is issued. EV certificates are typically used by banks and financial institutions, as well as e-commerce applications.
Organization certificates: These are typically used by corporate entities and help to identify employees for secure web transactions and email communication.
Client / Personal certificates: These are “digital IDs” that help to verify an individual’s identity and also help to control the access that individuals have to information and data. In general, certificate-based authentication is far superior to a traditional User ID and password-based authentication mechanism. Personal certificates can also be used for document signing purposes. These certificates are also helpful in Business to Business (B2B) scenarios – for example, allowing suppliers and partners to access and update specific information such as shipping dates or inventory availability.
Code signing certificates: These provide the ability to digitally sign software before it is distributed, typically over the internet, for downloading. These certificates help the recipients downloading and installing software to verify that the code is from an authentic source and that it has not been altered e.g. by the insertion of malware before reaching the recipient.
The X.509 Standard
Most digital certificates today are based on the X.509 standard, defined by the International Telecommunications Union (ITU). X.509 specifies a certificate format with a standard set of fields as indicated below.
Version number: Identifies which version of the X.509 standard the certificate is based on
Public key: This is the public key of the certificate holder
Serial number:This is a unique number to identify the certificate and distinguish it from other certificates issued by the same entity.
Certificate holder’s unique identifier: This is also known as a Distinguished Name (DN) and is intended to uniquely identify the certificate holder across the internet. The DN consists of fields such as Common Name (CN), Email, Organizational Unit (OU), Organization (O), and Country (C).
Validity period: This includes the date/time when the certificate was issued, and the expiration date/time.
Issuer unique name:This is the unique name of the entity that issued the certificate, usually a Certificate Authority (CA). Using the certificate implies that you trust the CA that issued the certificate.
Issuer digital signature:This is the digital signature of the CA, generated using the private key of the CA which can be verified through the CA’s public key.
Signature algorithm: This identifies the algorithm used by the CA to sign the certificate. One example of a popular algorithm used for signing certificates is the Secure Hash Algorithm (SHA) with a hash length of 256, also known as SHA256.
Certificate Extensions
Version 3 of the X.509 standard introduced certificate extensions, which can be used to provide additional information about the subject, apart from that contained in the standard fields. Examples of such additional information include alternative subject names or information on what the certificate can be used for, such as signing a digital object. Extensions are qualified as critical and non-critical and this defines how the additional information is to be processed by the recipient.
Certificate Keys
As described earlier in this article, PKI is based on asymmetric cryptography, which uses a public-private key pair. It is important to note that this key pair is created by the requestor and not by the issuing authority such as a CA. Requestors apply for a certificate by sharing their public key with the CA. The CA includes this public key in the certificate that it issues to the requestor. Certificate holders assert their identity by proving that they possess the private key corresponding to the public key in the certificate. Key protection and management
The most vulnerable aspect of PKI is the protection of private keys. If private keys are compromised, the entire system is compromised. Operating systems provide some basic features that can be used for key protection, an example being the Data Protection API (DPAPI) in Windows. For increased security however, one of the best practices is to use dedicated hardware appliances such as Hardware Security Modules (HSMs) and Trusted Platform Modules (TPMs). Such dedicated hardware based key protection solutions are a good option for large organizations who manage a large number of keys. For smaller organizations however, HSMs and TPMs could be an expensive option and alternatives such as virtual appliances and cloud key management solutions could be more suitable.
Certificate stores
A certificate store is a repository used by the certificate holder to store digital certificates. This is usually a special location in the file system provided by the operating system. The Windows operating system for example, provides the following types of certificate stores:
Local Machine Certificate Store: This is local to the computer and global for all the users. It is located in the system registry under HKEY_LOCAL_MACHINE, examples being HKEY_LOCAL_MACHINESOFTWAREMicrosoftSystemCertificates and HKEY_LOCAL_MACHINESOFTWAREMicrosoftEnterpriseCertificates
Current User Certificate Store: This is local to a user account on the computer and located in the system registry under HKEY_CURRENT_USER, an example being HKEY_CURRENT_USERSoftwareMicrosoftSystemCertificates
Trusted Root CA Certificate Store: This contains the root certificates of all the CAs that are trusted by the Windows operating system. Administrators can modify the default set of trusted CAs and also manually install the root certificate of their own private CA.
Trusted Publishers Certificate Store: This contains information about code signing certificates of trusted publishers that are installed on a computer. Administrators can modify the default set of trusted publishers and manually install code signing certificates into the trusted publishers certificate store.
Code signing is the process of applying a digital signature to any software program that is intended for release and distribution to another party or user, with two key objectives. One is to prove the authenticity and ownership of the software. The second is to prove the integrity of the software i.e. prove that the software has not been tampered with, for example by the insertion of any malicious code. Code signing applies to any type of software: executables, archives, drivers, firmware, libraries, packages, patches, and updates. An introduction to code signing has been provided in earlier articles on this blog. In this article, we look at some of the business benefits of signing code.
Reduction in financial risk
As per recent research, the average cost of a malware attack is around $2.6 million1 and this poses a big financial risk to any organization. One of the root causes for malware is when software is installed without verifying whether the software is authentic and without confirming who is the owner of the software. Another source of malware attacks could be when attackers tamper with software from a source that the customer trusts and insert malicious code inside that software. Code signing addresses both these problems.
One point to note is that while code signing is necessary, it is not sufficient to prevent malware – for example, if the keys used for code signing certificates are themselves compromised. Management of keys therefore is an equally important area of focus and will be covered in a separate article.
Improved brand and reputation
Apart from the financial impact, a malware attack also results in a reputation impact, rapidly damaging organization credibility and raising questions about the security practices of any company. Code signing provides a “digital shrink wrap” seal to your software – it confirms software authenticity to your customer and warns the customer if the seal has been tampered with. For example, even if a single bit in the software is modified, the hash used to sign the software will not match with the hash for the downloaded software – warning the customer not to install the software and thereby preventing a breach. The net effect is to improve your company’s brand and reputation in the eyes of your customers.
Increase in customer trust
Without code signing, security warnings and alerts are shown to the user by the browser and operating system – introducing an element of doubt into the user’s mind and a subsequent loss of customer trust in the software. Customer trust can be further eroded by a malware attack, especially if the root cause analysis points to the lack of code signing being one of the reasons for the attack. Signing code is a great way of building customer confidence and trust by conveying to customers that the organization is doing whatever is possible to ensure the security and integrity of the software it is distributing.
Increasing the distribution reach and install base for your software
Online distribution of the software is becoming de-facto today considering the speed to market, reduced costs, scale, and efficiency advantages over traditional software distribution channels such as retail stores or software CDs shipped to customers. Code signing is a must for online distribution. For example, third party software publishing platforms increasingly require applications (both desktop as well as mobile) to be signed before agreeing to publish them.
Even if you are able to reach a large number of users, without code signing, the warnings shown during download and install of unsigned software are often enough to discourage the user from proceeding with the download and install. In fact, the overall trend is for operating systems to make it increasingly difficult for users to install unsigned software by asking users to go through multiple manual steps and override default security settings. In enterprises, unsigned software can often make it to the “blacklist” or list of software prohibited by the IT team from being downloaded and installed. Code signing can address these issues, help software publishers reach a larger audience, and increase the overall download rates and install base for software. 1As per a study from Accenture and Ponemon institutehttps://www.helpnetsecurity.com/2019/03/07/cyberattack-cost-2018/
What is Personally Identifiable Information (PII)?
The digital age of today is powered by customer and consumer data: data is the new currency. Provided it is collected through consent and transparency, consumer data is the key for enterprises to create value for their consumers, for example through personalization and transformed experiences. Among the various attributes of consumer data are those which can be used to uniquely identify the consumer – the set of such data is called Personally Identifiable Information (PII). Examples of PII include name, email address, telephone number, address, and other attributes related with the individual’s demographic, financial, health and any other personal details.
The need for enterprises to protect PII
With regulations such as the California Consumer Protection Act (CCPA) in the USA, General Data Protection Regulation (GDPR) in Europe and similar ones in other parts of the world, enterprises are under increasing legal obligations to protect PII data. As consumer awareness increases, each data breach causes a significant dent in consumer trust and consequently, the organization’s brand and reputation. However, it’s not just about brand and reputation: recent research indicates that each data breach has a financial impact of $4 million. With threats and vulnerabilities constantly on the rise, the need for enterprises to protect PII data is more today than ever before.
Encryption of PII Data
Encryption is one of the proven ways to protect PII data. Once consumer data is encrypted, the risk of a data breach can be mitigated to a large extent, and the impact of the breach can be contained – since the stolen data will be of no use to the attacker in an encrypted form. Apart from risk mitigation, PII data encryption is also necessary from a compliance perspective, with regulations such as CCPA and GDPR mentioned earlier, mandating such encryption.
What to encrypt?
The first step in PII data encryption is to decide what data to encrypt: and data privacy regulations offer a good starting point. For example, the HIPAA (Health Insurance Portability and Accountability Act) regulations in the US defines the patient information that needs to be encrypted, including treatment information. One point to note is that while regulations indicate what data is to be encrypted, they leave the choice of the encryption technology to the enterprise.
Locating the data
Once the data to be encrypted is identified, the next step is in locating the data across the enterprise, as a part of a data discovery exercise. This is essential because PII data could be stored in multiple applications, databases, and file systems across the enterprise, or in the cloud. The data discovery exercise typically involves an application and system portfolio study or assessment, along with the use of data discovery tools.
Encryption Technologies & Standards
The next step is the actual encryption of the data. There are multiple encryption technologies and standards available and let’s take a look at the most popular ones.
Advanced Encryption Standard (AES): AES is one of the best encryption options primarily due to its strength and widespread acceptability. As one of the strongest encryption technologies available, AES enjoys widespread acceptability across regulations, enterprises, credit card issuers, and government agencies. AES is also used in the Pretty Good Privacy (PGP) standard which is used by a large number of banking and financial services institutions. The National Institute of Standards and Technology (NIST) recommends AES as the highest standard for encryption, with three different key sizes: 128 bit, 192 bit, and 256 bits.
RSA: This is an encryption standard named after its three inventors: Rivest, Shamir and Adleman. The strength of RSA is derived from the fact that prime factorization of very large numbers is computationally extremely difficult with existing hardware and compute resources. RSA has become popular since it can help assure the confidentiality, integrity, authenticity, and non-repudiation of data. Key lengths in RSA are very long at 1024 or 2048 bits and this is another reason for RSA’s strength. With these key lengths, the algorithm however is relatively slow and therefore one application of RSA is to use it for key encryption instead of direct data encryption. Another limitation of RSA is that as computers get more powerful, key lengths need to get longer and longer in order to stay ahead of brute force attempts at prime factorization.
Elliptic Curve Cryptography (ECC): This is emerging as a popular alternative to RSA due to its advantages of speed, smaller key sizes, and cryptographic efficiency. ECC is also a good option for mobile devices due to its lower requirements on compute power and battery use. The algorithm is based on algebraic equations that represent elliptic curves. Keys generated through this approach are mathematically several orders of magnitude stronger than the prime factorization approach of RSA. For example, a 256 bit ECC key has the same strength as a 3072 bit RSA key.
SSL/TLS: The Secure Sockets Layer (SSL) protocol and its successor, Transport Layer Security (TLS) have now become mainstream with web servers and browsers being a familiar example of their usage. With PII data often being sent over the network from client to server, from one application to another and from one server to another, communication channel encryption using SSL/TLS is critical to avoid “man in the middle” attacks. At the heart of SSL/TLS is a handshake protocol between the two endpoints and secured using asymmetric cryptography, which is used to generate a session key that is valid only for that communication session. The rest of the communication over the channel is encrypted using a symmetric cryptography approach, with this session key used by both endpoints. The SSL/TLS protocol ensures both security as well as performance and has become the de-facto encryption standard for data in motion not just between a web browser and server, but across any two endpoints.
Key Management: The ultimate success of any data encryption technology does not depend on the algorithms, hardware and software used: it depends on how well the private keys used for encryption are managed. The fundamental requirement for key management is to separate the encrypted data and the encryption keys into distinct physical locations. Options for key management include Hardware Security Modules (HSM), Virtual appliances, and Cloud key management services.
Key Takeaways
Any enterprise that handles personally identifiable information (PII) of consumers is also responsible for protecting that data. Data breaches pose three significant business risks to any organization: loss of consumer trust, direct financial impact, and legal / regulatory implications and penalties. Encryption technologies offer a proven means for enterprises to protect PII data and address all three risks.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
