LDAPS is one of the most crucial functionalities to properly protect and secure credentials in your PKI environment. By default, LDAP communications between client and server applications are not encrypted. This means that it would be possible to use a network monitoring device or software and view the communications traveling between LDAP client and server computers. This is especially problematic when an LDAP simple bind is used because credentials (username and password) are passed over the network unencrypted. This could quickly lead to the compromise of credentials.
Prerequisites
A functional Microsoft PKI should be available and configured. While viewing PKIView.msc, no errors should appear
If you need help in deploying your own PKI, you can refer to this article to build your own Two Tier PKI
Installing AD LDS
This step should be carried out on LDAP Server or on Domain Controllers which would be responsible for hosting LDAPS service.
Open Server Manager
From manage, open Add Roles and Features
On Before you Begin, click Next
On Installation type, ensure Role based or feature based installation, and click Next
On Server Selection, click Next.
On Server Roles, click Active Directory Lightweight Directory Services, and click Add Features, and then click Next
On Features, click Next
On AD LDS, click Next
On Confirmation, click Install
Post Installation, AD LDS needs to be configured
Configuring AD LDS
Run AD LDS setup wizard. Click Next on first page.
Ensure unique instance is selected, and click Next
Provide Instance name and Description, and click Next
Leave default ports and click Next
If AD LDS is installed on domain controller, then LDAP port would be 50000 and SSL port would be 50001
On Application Directory Partition, click Next
On File locations, click Next
On Service Account Selection, you may leave it on the Network service account, or choose a preferred account that can control LDAPS service
On AD LDS administrators, leave the current admin, or choose another account from the domain
Choose all LDF Files to be imported, and click Next
On Ready to Install, click Next
After Installation, click Finish
Publishing a certificate that supports Server Authentication
Login to the Issuing CA as enterprise admin
Ensure you are in Server Manager
From the Tools menu, open Certificate Authority
Expand the console tree, and right click on Certificate Templates
Select Kerberos Authentication (as it provides Server Authentication). Right click and select Duplicate Template. We can now customize the template.
Change Template Display Name and Template Name on General tab. Check Publish Certificate in Active Directory. This will ensure that the certificate appears when we enrol domain controllers using that template
On Request Handling, check Allow private key to be exported.
On the Security tab, provide Enroll permissions to appropriate users
Click Apply
Issue the Certificate on Issuing CA
Login to the Issuing CA as enterprise admin
Ensure you are in Server Manager
From the Tools menu, open Certificate Authority
Expand the console tree, and click on Certificate Templates
On the menu bar, click Action > New > Certificate Template to Issue
Choose the LDAPS certificate
Click OK and it should now appear in Certificate Templates
Requesting a certificate for Server Authentication
Log into LDAP server or domain controller.
Type win+R and run mmc
Click File and click Add/Remove Snap-in
Choose Certificates and click Add
Choose Computer account
If the steps are followed on LDAPServer where AD LDS is installed, click Local computer, or choose Another computer and choose where it would need to be installed
Expand the console tree, and inside Personal, click Certificates
Right click on Certificates and click All Tasks and select Request New Certificate
Follow the instructions, choose LDAPS template that we issued earlier and Install.}
Once Installed click Finish
Open the certificate, and in Details tab, navigate to Enhanced Key Usage to ensure Server Authentication is present.
Validating LDAPS connection
Login to LDAP Server as Enterprise admin
Type win+R and run ldp.exe
On the top menu, click on Connections, and then click Connect
In server, provide domain name, ensure SSL is checked and proper port is provided and click OK
No errors should appear. If connection was unsuccessful, the following output may appear
Conclusion
This should enable LDAPS which can be used to properly protect credentials used in your PKI environment as well as enable other applications to use LDAPS.
Anish Bhattacharya is a Consultant at Encryption Consulting, working with PKIs, HSMs, creating Google Cloud applications, and working as a consultant with high-profile clients.
Trust is crucial in the software-driven society we live in. But how can we tell which software to rely on and which to avoid? We can thank code signing for that.
Developers use code signing to demonstrate a piece of software’s legitimacy and ensure that it originates from a reliable source and hasn’t been tampered with. Cryptography, more especially a certificate known as a code signing certificate, is necessary for code signing.
Customers should constantly be on the lookout for third parties posing as software providers while downloading software from the Internet. Software may be ensured that it is coming from the right source with the use of a tool like code signing. To ensure that consumers are receiving software that accomplishes what its creator claims it will, code signing is a process where a software developer or distributor digitally signs the file being sent out. The signature indicates that the code has not been altered from its original state.
Benefits of Code Signing
Code signing is a technique for adding a digital signature to a program, file, software update, or executable so that, upon installation and execution, its validity and integrity can be checked. It ensures to the receiver who the author is and that it hasn’t been opened and tampered with, much like a wax seal. To demonstrate, for instance, that your Windows 10 update genuinely came from Microsoft and not a hacker attempting to breach your machine, Microsoft developers, programmers, and software engineers utilize code signing.
You can be confident that you are downloading a file from a legitimate author or publisher and not from an attacker trying to steal your personal information and data thanks to code signing. In essence, it informs you that a bad guy hasn’t changed the code so you know it’s safe to install and run on your machine.
If you’ve ever seen the small window that appears when you attempt to launch a software you’ve downloaded, the one that asks, “Are you sure you want to run this? ” and identifies the publisher, then you know what I’m talking about. then you have experienced code signing. That dialogue box informs you that the patch for your Mac OS X is authentic and still in the same state as when it was signed by Apple Inc.
What Does Code Signing Do?
As a user, code signing serves a few distinct purposes that might assist you in determining if you should trust software downloads and other online interactions. Code signing is mostly used to verify the authorship of files, downloads, and software. For instance, you are more likely to install a download file supplied to you from Microsoft than one from any other source since it will seem to be much more reliable.
There will inevitably be updates for the software you install on your computer in the future. You may be sure that subsequent updates have come from the same source and are secure to run on your computer when they are code signed with the same key that was used to “seal” your initial downloads.
How Does Code Signing Work?
From the perspective of a developer, code signing has three main parts: unsigned software files; code-signing certificates; and code-signing apps. Applications for code signing are typically included with operating systems like Microsoft Windows, Mac OS X, etc. Certificate Authorities are frequently the source of the code signing certificates (CAs).
Public Key Encryption
When you encode a message to shield it from unauthorized viewers, you are using encryption. Decoding the message depends on knowing the key that puts the values back to their original state, enabling the message to be read. Typically, this is done by running it through a mathematical function (referred to as a “key”) to alter values. The key that encrypts the message and the key that decrypts it is distinct in public key encryption (also known as asymmetric encryption) (hence asymmetrical). It is known as a “public key” system because only one key—the “public key”—is used to secure the communication, while the other—the “private key”—is kept secret.
Private keys must be kept secure, confidential, and out of the hands of anybody who would try to intercept or tamper with messages in order for this type of encryption to work. The kind of transmission determines whether the public key is used to encode or decode the message. Encrypt using the private key and decode with the public key if you want everyone to be able to read the message but don’t want anyone to tamper with it. You encrypt using the public key but decode with the private key if you want everyone to be able to send messages but don’t want them intercepted by the incorrect person.
Hash Function
A form of encryption called hash functions is intended to be irreversible. Hash functions are designed to be one-way, utilizing a mathematical function that modifies the data in a way that can’t be undone, as opposed to encoding with a key and using a key to decode. The most typical comparison is like mixing paint. As an illustration, mixing blue (the original values) and yellow (the hash function) will always result in green, but there is no way to separate the two colors and get back the blue.
When you require a set value and don’t need to read the data again, hash functions are utilized. The most prevalent example is login passwords, which are frequently hashed by websites for storage. If there is ever a breach, all the hacker has obtained is a collection of random numbers. The website hashes your password once again and compares it to the previously saved hash value when you log in. They let you in if the information you provided matches what is in their records. They only need to know the value; they don’t need to read the password itself.
Code Signing Certificates
Before the developers can sign their work, they need to generate a public/private key pair. This is often done locally through software tools such as ‘OpenSSL’. Developers then give the public key and the organization’s identity information to a trustworthy CA. The CA verifies the authenticity of identity information and then issues the certificate to the developer. This is the code signing certificate which was signed by CA’s private key and contains the developer organization’s identity and the developer’s public key.
Developers take all the code they produced and hash it when they’re ready to “sign” it to prove authorship. The output value is then encoded using the previously stated private key, which is often created by the author, as well as the code signing certificate, which contains the public key and the author’s identity (proving the authorship). The result of this procedure is then included in the program that will be distributed.
This is an instance of code signing. The majority of browsers and operating systems come with the public key of the CA pre-installed. When a user downloads the program, they first authenticate the legitimacy of the code signing certificate incorporated in the signed software to ensure it’s from a reliable CA using the CA’s public key. The encrypted hash is then decrypted using the developer’s public key, which is subsequently taken out of the certificate.
The program is then hashed once more, and the result is contrasted with the decrypted value. The program has not been tampered with or damaged during transmission if the hash values generated by the user and the developer coincide. The user is then informed that the program is in the same condition as when the developer last left it and that it is safe to install and execute if the developer can be believed.
Root Certificates
Code signing can provide you, the end user, confidence in the reliability and validity of the downloaded program. However, you should also be mindful that malicious actors may produce a code signing certificate and a public-private key pair to give the impression that they were authorized by a legitimate CA. How do you determine whether certificates are reliable if anybody can create a code signing certificate?
Root certificates have a role in this. Code signing certificates can be compared to a family tree. You may trace certificates back to discover which signing certificate—your root certificate—is at the root of the tree in order to confirm where they originated. Because you can follow the “chain of trust” back to the initial signing authority with the root certificate, you can tell whether the other code signing certificates are reliable.
A business like Apple or Microsoft might be considered the root authority. The system will warn you not to trust the certificate that was used to sign the program you are attempting to download if your software’s signing certificate is unable to locate a reliable root certificate. Even a trusted authority may occasionally fail to be recognized if it is not installed on a browser or in the trust store of an operating system. For the browser or operating system to accept the root certificate as reliable and valid in these situations, you will need to manually put it on your trust store.
What Are the Types of Digital Certificates?
Different systems require different types of authentication. What works on a desktop is likely unsuitable for mobile systems and vice versa. Here are a few examples of the different certificates for both desktop and mobile software.
Desktop Certificates:
Microsoft
Java
Microsoft Office and VBA
Adobe AI
Mobile Certificates:
Windows Phone
Windows Phone Private Enterprise
Java Verified
Android
If you’re looking to sign and secure your software, you should first know what kind of software or system you are starting with and work from there.
What is the Use of a Digital Certificate?
A digital certificate is meant to provide the software or code you’re distributing to your users with an identity. Users can verify the program publisher using a digital certificate. Because these digital certificates are issued by certificate authorities, users have more faith in the publishers. The ability to track their product and the number of downloads gives digital certificates to software providers a lot of additional value.
How Long is a Digital Certificate Valid?
How long a certificate is valid is another typical query from those trying to obtain their own digital code signing certificate. Digital certificates normally only have a year or two of validity, however, the actual duration might vary depending on the issuer.
This validity is brief for the following two reasons:
Private keys and security certificates may and do become hacked. Any prior certifications, even those that have been stolen, become invalid upon renewal and change every year or two.
Technology is evolving at an even quicker rate than the rest of the globe. Five years ago, what was secure is no longer nearly as secure. Code signing certificates can be updated and changed to keep the certificate security current.
Where is Code Signing Used?
Code signing is used any place a developer wants a user to be sure of the source of a piece of software. This includes:
1. Windows applications and software patches
2. Apple software
3. Microsoft Office VBA objects and macros
4. .jar files
5. .air or .airi files
6. Essentially any executable
Be aware that, because of the distributed nature of Linux development, code signing is often not used for Linux-based software, so that software may come unsigned. If that happens, your computer will (if it gives any notice) will tell you it’s from an “unknown developer,” or something along those lines. Here are a few other applications and software that utilize code signing to increase their security.
iOS: Code signing in iOS for the App Store is done using Xcode. The purpose of signing your app is simply to let iOS know who signed the app originally and to make sure it hasn’t been altered since it was originally signed by the developer. If you need to revoke your iOS certificate, you will need to use your developer account or Xcode to complete the process.
Xcode: Xcode is used by iOS to code sign apps and ensure their security. Before any device can be uploaded and approved for the iTunes store it must have a valid Apple Developer ID with a valid certificate or profile. To successfully integrate your app, you will need to use a development certificate. In order to run the app on any device, you must use a distribution certificate to send out the app and test it.
C#: Visual C# uses strong name signing to get a unique sign code that is not available to anyone else in the world and cannot be spoofed. When using Visual C#, you can simply sign your deployment using the sn.exe tool. This functions as your signature by using sig check tool printing “Strong Name: Signed.”
Windows Certificate: Nearly any executable can be signed with a digital signature to verify the security and integrity of the file. For the file to be considered secure in Windows, it must be signed by a recognized certificate authority. Anyone who distributes malware under a valid certificate is held legally accountable for the software they distribute.
Visual Studio: Visual Studio is particularly helpful when it comes to strong name signing for assemblies—a notoriously difficult task. Strong name signing through Visual Studio allows other computers to trust the software developer.
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.
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.
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.
