Activity Not Available
4
I Use This!

News

Analyzed 2 months ago. based on code collected 3 months ago.
Posted 3 months ago by nore...@blogger.com (tomas)
The new eIDAS regulation that has been adopted in the EU (by 1 July 2016) comes with a new set of standard documents from ETSI, specifying particular requirements on PKI. The two new eIDAS standards relevant for PKI are: EN 319 411 - Policy and ... [More] security requirements for Trust Service Providers issuing certificates EN 319 412 - Certificate Profiles The standards are maintained by the standardization body ETSI and can be downloaded from the ETSI download area.What new requirements do these standards come with? Looking closely there are only two new things needed to be able to claim "eIDAS compliance": A new DN attribute organizationIdentifier New fields in the QCStatement certificate extension Let's dig a little deeper into these two requirements. OrganizationIdentifierOrganizationIdentifier is a DN attribute with OID 2.5.4.97 specified in X.520. This is an attribute that has, to my knowledge, never been in common use in certificates before. Its usage in the eIDAS context is described in the following sections of EN 319 412: EN 319 412-1 section 5.1.1 and 5.1.4 EN 319 412-2 section 4.2.3.1 and 4.2.4 EN 319 412-3 section 4.2.1 OrganizationIdentifier is supported in EJBCA Enterprise PKI from version 6.5.2. QCStatementThere is already a QCStatement extension in use since long. With the new standards comes a few additions.The new items in the QCStatement extension are: QcType, claiming that the certificate is a EU qualified certificate of a particular type PdsLocation, location of PKI Disclosure Statements (PDS) The QCStatement is described in: EN 319 411-2 section 6.6.1 EN 319 412-1 section 5.1.1 and 5.1.2 EN 319 412-2 section 5.1 and 5.2 EN 319 412-4 section 4.2 EN 319 412-5, full technical description With the convenient ability to define custom extensions in the EJBCA GUI (since EJBCA 6.4.0) the new QCStatement extension can be easily added to any certificate profile. EJBCA Enterprise We strive to support all relevant open PKI standards and it is important to keep EJBCA Enterprise up to date with new and emerging standards. Since EJBCA 6.5.2 eIDAS compliance should be easily achieved on the level of PKI. More information   Basic information on EJBCA Enterprise PKI and PKI Appliance developed by PrimeKey. EJBCA is a registered trademark of PrimeKey Solutions AB in the EU, the United States, Japan and certain other countries. [Less]
Posted 3 months ago by nore...@blogger.com (tomas)
The new eIDAS regulation that has been adopted in the EU (by 1 July 2016) comes with a new set of standard documents from ETSI, specifying particular requirements on PKI. The two new eIDAS standards relevant for PKI are:EN 319 411 - Policy and ... [More] security requirements for Trust Service Providers issuing certificatesEN 319 412 - Certificate ProfilesThe standards are maintained by the standardization body ETSI and can be downloaded from the ETSI download area.What new requirements do these standards come with? Looking closely there are only two new things needed to be able to claim "eIDAS compliance":A new DN attribute organizationIdentifierNew fields in the QCStatement certificate extensionLet's dig a little deeper into these two requirements.OrganizationIdentifierOrganizationIdentifier is a DN attribute with OID 2.5.4.97 specified in X.520. This is an attribute that has, to my knowledge, never been in common use in certificates before. Its usage in the eIDAS context is described in the following sections of EN 319 412:EN 319 412-1 section 5.1.1 and 5.1.4EN 319 412-2 section 4.2.3.1 and 4.2.4EN 319 412-3 section 4.2.1OrganizationIdentifier is supported in EJBCA Enterprise PKI from version 6.5.2.QCStatementThere is already a QCStatement extension in use since long. With the new standards comes a few additions.The new items in the QCStatement extension are:QcType, claiming that the certificate is a EU qualified certificate of a particular typePdsLocation, location of PKI Disclosure Statements (PDS)The QCStatement is described in:EN 319 411-2 section 6.6.1EN 319 412-1 section 5.1.1 and 5.1.2EN 319 412-2 section 5.1 and 5.2EN 319 412-4 section 4.2EN 319 412-5, full technical descriptionWith the convenient ability to define custom extensions in the EJBCA GUI (since EJBCA 6.4.0) the new QCStatement extension can be easily added to any certificate profile.EJBCA EnterpriseWe strive to support all relevant open PKI standards and it is important to keep EJBCA Enterprise up to date with new and emerging standards. Since EJBCA 6.5.2 eIDAS compliance should be easily achieved on the level of PKI.More information  Basic information on EJBCA Enterprise PKI and PKI Appliance developed by PrimeKey.EJBCA is a registered trademark of PrimeKey Solutions AB in the EU, the United States, Japan and certain other countries. [Less]
Posted 5 months ago by nore...@blogger.com (tomas)
A USB standard for authentication of devices has been released a little while ago [1] as part of USB 3.1. In short, the standard specifies the use of: X509v3, DER encoding certificates  ECDSA using the NIST P256 (a.k.a. secp256r1) curve ... [More] , uncompressed point format  SHA256  SubjectDN fields should be: CN: USB: O: organization name attribute shall contain the human-readable name of the organization that owns the private key  DN Serial Number: lowercase hex-encoded value of the binary data (e.g. wafer number, lot number, production lot, etc.) necessary for uniqueness.  In addition, there is one new certificate extension:Custom certificate extension USB-IF ACD (OID 2.23.145.1.2): Seems to contain static data in an OCTET STRING, which can be added via EJBCA Admin GUI. Conclusion: EJBCA should be able to issue such certificates. [1] "USB Authentication Specification Rev. 1.0, March 25, 2016" http://www.usb.org/developers/docs/ [Less]
Posted 5 months ago by nore...@blogger.com (tomas)
A USB standard for authentication of devices has been released a little while ago [1] as part of USB 3.1. In short, the standard specifies the use of:X509v3, DER encoding certificates ECDSA using the NIST P256 (a.k.a. secp256r1) curve, uncompressed ... [More] point format SHA256 SubjectDN fields should be:CN: USB:<vendor ID&gt:<product ID&gtO: organization name attribute shall contain the human-readable name of the organization that owns the private key DN Serial Number: lowercase hex-encoded value of the binary data (e.g. wafer number, lot number, production lot, etc.) necessary for uniqueness. In addition, there is one new certificate extension:Custom certificate extension USB-IF ACD (OID 2.23.145.1.2): Seems to contain static data in an OCTET STRING, which can be added via EJBCA Admin GUI. Conclusion: EJBCA should be able to issue such certificates. [1] "USB Authentication Specification Rev. 1.0, March 25, 2016" http://www.usb.org/developers/docs/ [Less]
Posted 9 months ago by nore...@blogger.com (tomas)
This blog post is based on my 'Hardcore PKI' presentation at PrimeKey Tech Days 2015. The EJBCA functions described can help you integrate PKI more efficiently for specific use cases.What is hardcore PKI? Technologies such as ASN.1 and X.509, RSA and ... [More] ECC Standards and APIs are extremely complex for most users and developers, and the important process of fitting them all together in standards (to enable interoperable systems) is very hard. However, implementors of PKI systems don't have to care about these hardcore technologies due to a few helpful tools: ASN.1 parsing is done using the library BouncyCastle.  Digital signatures with RSA and ECC is also done either using BouncyCastle in software, or it is done in Hardware Security Modules. Standardization is done by organizations such as IEFT and Oasis. When people think about PKI they often think about hardcore technologies, but because of these handy tools, the technologies themselves are not what is hardcore about PKI.The Devil is in the Detail Hardcore PKI, in my opinion, is that everybody needs and uses PKI, but always in slightly different ways. This demands from the PKI to have the ability to support a lot of different architectures (which EJBCA does) and from you to be able to configure and fine tune your PKI according to your precise needs. The devil is in the details!The many possibilities of configuring several details is really the hardcore part in PKI.Thirteen EJBCA options explainedHere are thirteen examples of hardcore details that can truly make your PKI better integrated. But unless you are looking for one or more of these specific features,  these options may appear somewhat incomprehensible. One reason for EJBCA to provide all these functions is to support policy enforcement all the way from Complete Enforcement by the CA, to All Enforcement in the RA (where the CA trusts the RA blindly).On to the details! Most of the options are also described in the EJBCA User Guide.Permissions EJBCA Certificate Profile options: override and certificate storage Allow validity override – Normally validity is determined by the certificate profiles, but with this option the validity period can be taken from the request sent by the client/RA. Allow extension override – Normally certificate extensions are determined by the certificate profiles, but with this option the extensions can be taken from the request sent by the client/RA. Allow DN override – Normally the DN is pre-registered and determined by the end entity record, but with this option the DN can be taken from the request sent by the client/RA. Use Certificate storage – An interesting option where you can choose to not store issued certificates in the CA database. This fits specific use cases where revocation never needs to happen and you want to issue large amounts of certificates without the burden of administrating a growing CA database. A kind of fire and forget CA. Other data EJBCA Certificate Profile options: CN postfix and single active certificate Use CN postfix – tells the CA to add some text after the CN in the issued certificate. Can be used to get user friendly names (like 'Tomas – Encryption' and 'Tomas – Signing') in browser certificate dialogues. Use DN and altName subset – use this if you want to register more information about end entities, than is visible in the issued certificate. Approvals – enforces dual control (or four eyes principle) for certain functions such as revocation and key recovery. Single Active Certificate Constraint – automatically revokes an end entity's old certificate when a new certificate is retrieved. This ensures that a user or device can only use one certificate at a certain point in time. Directives EJBCA Certificate Profile options: enforce public key and DN Enforce unique public keys – makes two end entities unable to use the same public key. Enforce unique DN – makes two end entities unable to share the same subject DN. Enforce unique Subject DN SerialNumber - makes two end entities unable to share the same SerialNumber component in the Subject DN. The SerialNumber in the DN is typically used for device serial numbers, thus ensuring that one device is only registered as a single end entity. Use User Storage – when disabled, end entities are not stored in the database when issuing certificates through an RA capable protocol. Saves space in the database, but removes some functionality. Use Certificate Storage – when disabled, certificates are not stored in the database when issued. This option enables issuing of billions of certificates without using any storage space, but on the other hand disables several of the commonly required PKI functions such as revocation. The Key Take AwaysAll of the obscure functions described above are used in real life, for various use cases. Some very domain specific, some more generic. The key take away, is that these functions provide short-cuts for use cases where you thought you would have to do work-arounds, or be limited by the capabilities of a specific product. With the functions described (and several others) you can integrate PKI in your use case in the most efficient way, only having your imagination setting the boundaries.EJBCA EnterpriseIn EJBCA Enterprise we strive for maximum flexibility, only having a single platform to manage all needs of PKI. This means EJBCA has to be available for all platforms, and be ready to implement many protocols and multiple APIs, while enabling you to use your PKI from many locations. In order to do this we need to support many different PKI architectures (as was explained here).More informationBasic information on EJBCA Enterprise PKI and PKI Appliance developed by PrimeKey.EJBCA is a registered trademark of PrimeKey Solutions AB in the EU, the United States, Japan and certain other countries. [Less]
Posted 9 months ago by nore...@blogger.com (tomas)
This blog post is based on my 'Hardcore PKI' presentation at PrimeKey Tech Days 2015. The EJBCA functions described can help you integrate PKI more efficiently for specific use cases.What is hardcore PKI? Technologies such as ASN.1 and X.509, RSA and ... [More] ECC Standards and APIs are extremely complex for most users and developers, and the important process of fitting them all together in standards (to enable interoperable systems) is very hard. However, implementors of PKI systems don't have to care about these hardcore technologies due to a few helpful tools:ASN.1 parsing is done using the library BouncyCastle. Digital signatures with RSA and ECC is also done either using BouncyCastle in software, or it is done in Hardware Security Modules.Standardization is done by organizations such as IEFT and Oasis.When people think about PKI they often think about hardcore technologies, but because of these handy tools, the technologies themselves are not what is hardcore about PKI.The Devil is in the Detail Hardcore PKI, in my opinion, is that everybody needs and uses PKI, but always in slightly different ways. This demands from the PKI to have the ability to support a lot of different architectures (which EJBCA does) and from you to be able to configure and fine tune your PKI according to your precise needs. The devil is in the details!The many possibilities of configuring several details is really the hardcore part in PKI.Thirteen EJBCA options explainedHere are thirteen examples of details to boost your PKI and make it hardcore. But unless you are looking for one or more of these specific features,  these options may appear somewhat incomprehensible. One reason for EJBCA to provide all these functions is to support policy enforcement all the way from Complete Enforcement by the CA, to All Enforcement in the RA (where the CA trusts the RA blindly).On to the details! Most of the options are also described in the EJBCA User Guide.PermissionsEJBCA Certificate Profile options: override and certificate storageAllow validity override – Normally validity is determined by the certificate profiles, but with this option the validity period can be taken from the request sent by the client/RA.Allow extension override – Normally certificate extensions are determined by the certificate profiles, but with this option the extensions can be taken from the request sent by the client/RA.Allow DN override – Normally the DN is pre-registered and determined by the end entity record, but with this option the DN can be taken from the request sent by the client/RA.Use Certificate storage – An interesting option where you can choose to not store issued certificates in the CA database. This fits specific use cases where revocation never needs to happen and you want to issue large amounts of certificates without the burden of administrating a growing CA database. A kind of fire and forget CA. Other dataEJBCA Certificate Profile options: CN postfix and single active certificateUse CN postfix – tells the CA to add some text after the CN in the issued certificate. Can be used to get user friendly names (like 'Tomas – Encryption' and 'Tomas – Signing') in browser certificate dialogues.Use DN and altName subset – use this if you want to register more information about end entities, than is visible in the issued certificate.Approvals – enforces dual control (or four eyes principle) for certain functions such as revocation and key recovery.Single Active Certificate Constraint – automatically revokes an end entity's old certificate when a new certificate is retrieved. This ensures that a user or device can only use one certificate at a certain point in time.DirectivesEJBCA Certificate Profile options: enforce public key and DN Enforce unique public keys – makes two end entities unable to use the same public key.Enforce unique DN – makes two end entities unable to share the same subject DN.Enforce unique Subject DN SerialNumber - makes two end entities unable to share the same SerialNumber component in the Subject DN. The SerialNumber in the DN is typically used for device serial numbers, thus ensuring that one device is only registered as a single end entity.Use User Storage – when disabled, end entities are not stored in the database when issuing certificates through an RA capable protocol. Saves space in the database, but removes some functionality.Use Certificate Storage – when disabled, certificates are not stored in the database when issued. This option enables issuing of billions of certificates without using any storage space, but on the other hand disables several of the commonly required PKI functions such as revocation.The Key Take AwaysAll of the obscure functions described above are used in real life, for various use cases. Some very domain specific, some more generic. The key take away, is that these functions provide short-cuts for use cases where you thought you would have to do work-arounds, or be limited by the capabilities of a specific product. With the functions described (and several others) you can integrate PKI in your use case in the most efficient way, only having your imagination setting the boundaries.EJBCA EnterpriseIn EJBCA Enterprise we strive for maximum flexibility, only having a single platform to manage all needs of PKI. This means EJBCA has to be available for all platforms, and be ready to implement many protocols and multiple APIs, while enabling you to use your PKI from many locations. In order to do this we need to support many different PKI architectures (as was explained here).More informationBasic information on EJBCA Enterprise PKI and PKI Appliance developed by PrimeKey.EJBCA is a registered trademark of PrimeKey Solutions AB in the EU, the United States, Japan and certain other countries. [Less]
Posted 9 months ago by nore...@blogger.com (tomas)
This blog post is based on my 'Hardcore PKI' presentation at PrimeKey Tech Days 2015. The EJBCA functions described can help you integrate PKI more efficiently for specific use cases.What is hardcore PKI? Technologies such as ASN.1 and X.509, RSA and ... [More] ECC Standards and APIs are extremely complex for most users and developers, and the important process of fitting them all together in standards (to enable interoperable systems) is very hard. However, implementors of PKI systems don't have to care about these hardcore technologies due to a few helpful tools:ASN.1 parsing is done using the library BouncyCastle. Digital signatures with RSA and ECC is also done either using BouncyCastle in software, or it is done in Hardware Security Modules.Standardization is done by organizations such as IEFT and Oasis.When people think about PKI they often think about hardcore technologies, but because of these handy tools, the technologies themselves are not what is hardcore about PKI.The Devil is in the Detail Hardcore PKI, in my opinion, is that everybody needs and uses PKI, but always in slightly different ways. This demands from the PKI to have the ability to support a lot of different architectures (which EJBCA does) and from you to be able to configure and fine tune your PKI according to your precise needs. The devil is in the details!The many possibilities of configuring several details is really the hardcore part in PKI.Thirteen EJBCA options explainedHere are thirteen examples of hardcore details that can truly make your PKI better integrated. But unless you are looking for one or more of these specific features,  these options may appear somewhat incomprehensible. One reason for EJBCA to provide all these functions is to support policy enforcement all the way from Complete Enforcement by the CA, to All Enforcement in the RA (where the CA trusts the RA blindly).On to the details! Most of the options are also described in the EJBCA User Guide.PermissionsEJBCA Certificate Profile options: override and certificate storageAllow validity override – Normally validity is determined by the certificate profiles, but with this option the validity period can be taken from the request sent by the client/RA.Allow extension override – Normally certificate extensions are determined by the certificate profiles, but with this option the extensions can be taken from the request sent by the client/RA.Allow DN override – Normally the DN is pre-registered and determined by the end entity record, but with this option the DN can be taken from the request sent by the client/RA.Use Certificate storage – An interesting option where you can choose to not store issued certificates in the CA database. This fits specific use cases where revocation never needs to happen and you want to issue large amounts of certificates without the burden of administrating a growing CA database. A kind of fire and forget CA. Other dataEJBCA Certificate Profile options: CN postfix and single active certificateUse CN postfix – tells the CA to add some text after the CN in the issued certificate. Can be used to get user friendly names (like 'Tomas – Encryption' and 'Tomas – Signing') in browser certificate dialogues.Use DN and altName subset – use this if you want to register more information about end entities, than is visible in the issued certificate.Approvals – enforces dual control (or four eyes principle) for certain functions such as revocation and key recovery.Single Active Certificate Constraint – automatically revokes an end entity's old certificate when a new certificate is retrieved. This ensures that a user or device can only use one certificate at a certain point in time.DirectivesEJBCA Certificate Profile options: enforce public key and DN Enforce unique public keys – makes two end entities unable to use the same public key.Enforce unique DN – makes two end entities unable to share the same subject DN.Enforce unique Subject DN SerialNumber - makes two end entities unable to share the same SerialNumber component in the Subject DN. The SerialNumber in the DN is typically used for device serial numbers, thus ensuring that one device is only registered as a single end entity.Use User Storage – when disabled, end entities are not stored in the database when issuing certificates through an RA capable protocol. Saves space in the database, but removes some functionality.Use Certificate Storage – when disabled, certificates are not stored in the database when issued. This option enables issuing of billions of certificates without using any storage space, but on the other hand disables several of the commonly required PKI functions such as revocation.The Key Take AwaysAll of the obscure functions described above are used in real life, for various use cases. Some very domain specific, some more generic. The key take away, is that these functions provide short-cuts for use cases where you thought you would have to do work-arounds, or be limited by the capabilities of a specific product. With the functions described (and several others) you can integrate PKI in your use case in the most efficient way, only having your imagination setting the boundaries.EJBCA EnterpriseIn EJBCA Enterprise we strive for maximum flexibility, only having a single platform to manage all needs of PKI. This means EJBCA has to be available for all platforms, and be ready to implement many protocols and multiple APIs, while enabling you to use your PKI from many locations. In order to do this we need to support many different PKI architectures (as was explained here).More informationBasic information on EJBCA Enterprise PKI and PKI Appliance developed by PrimeKey.EJBCA is a registered trademark of PrimeKey Solutions AB in the EU, the United States, Japan and certain other countries. [Less]
Posted about 1 year ago by nore...@blogger.com (Anna Dilruba Christensen)
In this blog post we will focus on the support for signing Windows executables with SignServer Enterprise using Authenticode, one of the most popular formats.Digital Signatures and Central Code SigningWhenever software is being distributed over the ... [More] Internet (or other insecure network), or it is stored on untrusted media, it is crucial to use a reliable signing tool to digitally sign all executable files such as applications, libraries and drivers.Harmful code is today a real threat to users and organizations alike, as criminal groups and even governments use malicious software to steal and monitor data, extort money or empty your bank account.Digitally signed code ensures that the transferred software is trusted and unmodified. That is, as long as one picks a secure signing tool. Simply setting up any code signing tool you are able to find, may result in an insecure solution that makes you vulnerable to all sorts of attacks. PrimeKey's signing solution SignServer Enterprise, is proven and allows you to keep your code signing keys and certificates secure and audit ready.Code signing is crucial for distributing code in many systems:Windows executable files, libraries, drivers and updates.Firmware for hardware devices.Mobile apps (Android, iOS)OS X apps, XCode.Java applications (Applets, WebStart, Oracle Java).Plugins and addons in man applications (Mozilla, Firefox, Thunderbird XPI, NetBeans modules etc).Software from repositories for Linux and Apple OS X.Three good reasons to use Central SigningProtection of Signing KeysThe primary reason to use a secure, centralized code signing solution, is to keep code signing keys protected. For this purpose, keys are kept securely in a Hardware Security Module (HSM), mitigating the risk of any key being stolen or used illegitimately. Centralized controlMany organizations have code signing keys and certificates spread out in different departments and with different developers across the organization. Keeping track of where the signature capabilities reside, and who is allowed to sign code on the organization's behalf, quickly becomes difficult or even unmanageable.With the centralized signing solution the code signing capabilities are easily controlled from a single location, and the risk of code signing keys being lost or stolen is significantly decreased. The more efficient handling lowers the costs and you may even escape from buying code signing certificates for different people. Policy and Audit complianceAn organization needs to be able to see exactly when, and for what, a particular code signing key (and its certificate) has been used, and there are usually strict policies surrounding how code signing should be done.Using a central code signing solution makes it easy to achieve and enforce a strict audit record of who signed what. Some organizations demand this because of external audit requirements. While others need it to maintain trust in their brand, where maintaining good policy and audit records assure that the users of their products are not exposed to unnecessary risks of malicious software. Using SignServer for code signingSignServer is PrimeKey's code signing solution that helps you to keep secure control of your code signing keys, and also provides a centrally managed and audited single service for all your code signing needs.SignServer lets different project members or systems authenticate and share the same well protected code signing key and certificate when signing, and at the same time provides audit records of who signed what. For that matter, SignServer can also control individual code signing keys where only one person is granted authorization. SignServer Enterprise serves most code signing needs using different signers and custom plug-ins, and support for Authenticode was added from SignServer Enterprise 3.6.3. All you need to start signing code is a signature key pair, generated by SignServer, and a code signing certificate, issued by a private CA such as EJBCA or a public CA. Windows' Authenticode for executable filesMicrosoft has specified a format for digital signatures in software binaries called Authenticode. Using Authenticode, the signature is embedded within some type of portable executable (PE) file, typically with file endings like .exe, .dll, .sys and .ocx. In Windows, after an executable file has been downloaded and is about to be run, a security warning dialog box will appear (see picture below). At this moment the embedded signature has been verified, the code signing certificate has been verified that it was issued by a trusted CA, and the name of the publisher is displayed to the user. The dialog box asks the user to confirm if it is ok to start the application created by that publisher: Do you want to run this file? Publisher: Mozilla CorporationIf the file had not been signed, a different warning would be displayed, asking the user to confirm that the software should be run, even if the publisher is not known: The publisher could not be verified. Are you sure you want to run this software?More technical details are available in an Authenticode whitepaper published by Microsoft.Authenticode in SignServerSince SignServer Enterprise 3.6.3, there is an Authenticode signer for PE files. The signer is configured just like any other signer in SignServer. The only special requirement for this signer is to use a code signing certificate. If your organization already has a CA (for example EJBCA) configured to be trusted by your users, you can use that CA to issue the certificate. Otherwise you could buy a certificate from one of the CAs already trusted by default in Windows.For testing purposes, and also for test environments in general, you could issue the certificate yourself. Just remember to have the extended key usage “Code Signing” set and that you have to install the CA certificate in your test environment.You need to install the CA certificate in your test environment and remember to have the extended key usage set to “Code Signing”. In addition there are a few configuration options that can be applied to specify additional attributes, such as: the name of the application, if time stamping should be used, which service to use etc. Details of configuration options are documented in the SignServer Manual. After configuring and activating the signer, a user can sign code, for example by using the Generic Signing page, specifying the name of the signer and providing the binary to upload: Signer upload formAfter submitting the file, the signed version (with the embedded signature) is returned: Save signed fileIn Windows, the signature attached to a specific file can be manually inspected:Right click on the file and choose Properties.Click on the Digital Signatures tab.Select the signature in the Signatures list and click Details.Displaying the signature details on an executable fileIntegrationYou can use other interfaces of SignServer (such as the web service interface) to integrate code signing with other systems and applications in a completely transparent way.More informationBasic information on SignServer Enterprise and PrimeKey Code Signing Appliance is available at PrimeKey. [Less]
Posted about 1 year ago by nore...@blogger.com (Anna Dilruba Christensen)
In this blog post we will focus on the support for signing Windows executables with SignServer Enterprise using Authenticode, one of the most popular formats.Digital Signatures and Central Code SigningWhenever software is being distributed over the ... [More] Internet (or other insecure network), or it is stored on untrusted media, it is crucial to use a reliable signing tool to digitally sign all executable files such as applications, libraries and drivers.Harmful code is today a real threat to users and organizations alike, as criminal groups and even governments use malicious software to steal and monitor data, extort money or empty your bank account.Digitally signed code ensures that the transferred software is trusted and unmodified. That is, as long as one picks a secure signing tool. Simply setting up any code signing tool you are able to find, may result in an insecure solution that makes you vulnerable to all sorts of attacks. PrimeKey's signing solution SignServer Enterprise, is proven and allows you to keep your code signing keys and certificates secure and audit ready.Code signing is crucial for distributing code in many systems:Windows executable files, libraries, drivers and updates.Firmware for hardware devices.Mobile apps (Android, iOS)OS X apps, XCode.Java applications (Applets, WebStart, Oracle Java).Plugins and addons in man applications (Mozilla, Firefox, Thunderbird XPI, NetBeans modules etc).Software from repositories for Linux and Apple OS X.Three good reasons to use Central SigningProtection of Signing KeysThe primary reason to use a secure, centralized code signing solution, is to keep code signing keys protected. For this purpose, keys are kept securely in a Hardware Security Module (HSM), mitigating the risk of any key being stolen or used illegitimately. Centralized controlMany organizations have code signing keys and certificates spread out in different departments and with different developers across the organization. Keeping track of where the signature capabilities reside, and who is allowed to sign code on the organization's behalf, quickly becomes difficult or even unmanageable.With the centralized signing solution the code signing capabilities are easily controlled from a single location, and the risk of code signing keys being lost or stolen is significantly decreased. The more efficient handling lowers the costs and you may even escape from buying code signing certificates for different people. Policy and Audit complianceAn organization needs to be able to see exactly when, and for what, a particular code signing key (and its certificate) has been used, and there are usually strict policies surrounding how code signing should be done.Using a central code signing solution makes it easy to achieve and enforce a strict audit record of who signed what. Some organizations demand this because of external audit requirements. While others need it to maintain trust in their brand, where maintaining good policy and audit records assure that the users of their products are not exposed to unnecessary risks of malicious software. Using SignServer for code signingSignServer is PrimeKey's code signing solution that helps you to keep secure control of your code signing keys, and also provides a centrally managed and audited single service for all your code signing needs.SignServer lets different project members or systems authenticate and share the same well protected code signing key and certificate when signing, and at the same time provides audit records of who signed what. For that matter, SignServer can also control individual code signing keys where only one person is granted authorization. SignServer Enterprise serves most code signing needs using different signers and custom plug-ins, and support for Authenticode was added from SignServer Enterprise 3.6.3. All you need to start signing code is a signature key pair, generated by SignServer, and a code signing certificate, issued by a private CA such as EJBCA or a public CA. Windows' Authenticode for executable filesMicrosoft has specified a format for digital signatures in software binaries called Authenticode. Using Authenticode, the signature is embedded within some type of portable executable (PE) file, typically with file endings like .exe, .dll, .sys and .ocx. In Windows, after an executable file has been downloaded and is about to be run, a security warning dialog box will appear (see picture below). At this moment the embedded signature has been verified, the code signing certificate has been verified that it was issued by a trusted CA, and the name of the publisher is displayed to the user. The dialog box asks the user to confirm if it is ok to start the application created by that publisher: Do you want to run this file? Publisher: Mozilla CorporationIf the file had not been signed, a different warning would be displayed, asking the user to confirm that the software should be run, even if the publisher is not known: The publisher could not be verified. Are you sure you want to run this software?More technical details are available in an Authenticode whitepaper published by Microsoft.Authenticode in SignServerSince SignServer Enterprise 3.6.3, there is an Authenticode signer for PE files. The signer is configured just like any other signer in SignServer. The only special requirement for this signer is to use a code signing certificate. If your organization already has a CA (for example EJBCA) configured to be trusted by your users, you can use that CA to issue the certificate. Otherwise you could buy a certificate from one of the CAs already trusted by default in Windows.For testing purposes, and also for test environments in general, you could issue the certificate yourself. Just remember to have the extended key usage “Code Signing” set and that you have to install the CA certificate in your test environment.You need to install the CA certificate in your test environment and remember to have the extended key usage set to “Code Signing”. In addition there are a few configuration options that can be applied to specify additional attributes, such as: the name of the application, if time stamping should be used, which service to use etc. Details of configuration options are documented in the SignServer Manual. After configuring and activating the signer, a user can sign code, for example by using the Generic Signing page, specifying the name of the signer and providing the binary to upload: Signer upload formAfter submitting the file, the signed version (with the embedded signature) is returned: Save signed fileIn Windows, the signature attached to a specific file can be manually inspected:Right click on the file and choose Properties.Click on the Digital Signatures tab.Select the signature in the Signatures list and click Details.Displaying the signature details on an executable fileIntegrationYou can use other interfaces of SignServer (such as the web service interface) to integrate code signing with other systems and applications in a completely transparent way.More informationBasic information on SignServer Enterprise and PrimeKey Code Signing Appliance is available at PrimeKey. [Less]
Posted about 1 year ago by nore...@blogger.com (Dilruba Anna Christensen)
In this blog post we will focus on the support for signing Windows executables with SignServer Enterprise using Authenticode, one of the most popular formats.Digital Signatures and Central Code SigningWhenever software is being distributed over the ... [More] Internet (or other insecure network), or it is stored on untrusted media, it is crucial to use a reliable signing tool to digitally sign all executable files such as applications, libraries and drivers.Harmful code is today a real threat to users and organizations alike, as criminal groups and even governments use malicious software to steal and monitor data, extort money or empty your bank account.Digitally signed code ensures that the transferred software is trusted and unmodified. That is, as long as one picks a secure signing tool. Simply setting up any code signing tool you are able to find, may result in an insecure solution that makes you vulnerable to all sorts of attacks. PrimeKey's signing solution SignServer Enterprise, is proven and allows you to keep your code signing keys and certificates secure and audit ready.Code signing is crucial for distributing code in many systems: Windows executable files, libraries, drivers and updates. Firmware for hardware devices. Mobile apps (Android, iOS) OS X apps, XCode. Java applications (Applets, WebStart, Oracle Java). Plugins and addons in man applications (Mozilla, Firefox, Thunderbird XPI, NetBeans modules etc). Software from repositories for Linux and Apple OS X. Three good reasons to use Central SigningProtection of Signing KeysThe primary reason to use a secure, centralized code signing solution, is to keep code signing keys protected. For this purpose, keys are kept securely in a Hardware Security Module (HSM), mitigating the risk of any key being stolen or used illegitimately. Centralized controlMany organizations have code signing keys and certificates spread out in different departments and with different developers across the organization. Keeping track of where the signature capabilities reside, and who is allowed to sign code on the organization's behalf, quickly becomes difficult or even unmanageable.With the centralized signing solution the code signing capabilities are easily controlled from a single location, and the risk of code signing keys being lost or stolen is significantly decreased. The more efficient handling lowers the costs and you may even escape from buying code signing certificates for different people. Policy and Audit complianceAn organization needs to be able to see exactly when, and for what, a particular code signing key (and its certificate) has been used, and there are usually strict policies surrounding how code signing should be done.Using a central code signing solution makes it easy to achieve and enforce a strict audit record of who signed what. Some organizations demand this because of external audit requirements. While others need it to maintain trust in their brand, where maintaining good policy and audit records assure that the users of their products are not exposed to unnecessary risks of malicious software. Using SignServer for code signingSignServer is PrimeKey's code signing solution that helps you to keep secure control of your code signing keys, and also provides a centrally managed and audited single service for all your code signing needs.SignServer lets different project members or systems authenticate and share the same well protected code signing key and certificate when signing, and at the same time provides audit records of who signed what. For that matter, SignServer can also control individual code signing keys where only one person is granted authorization. SignServer Enterprise serves most code signing needs using different signers and custom plug-ins, and support for Authenticode was added from SignServer Enterprise 3.6.3. All you need to start signing code is a signature key pair, generated by SignServer, and a code signing certificate, issued by a private CA such as EJBCA or a public CA. Windows' Authenticode for executable filesMicrosoft has specified a format for digital signatures in software binaries called Authenticode. Using Authenticode, the signature is embedded within some type of portable executable (PE) file, typically with file endings like .exe, .dll, .sys and .ocx. In Windows, after an executable file has been downloaded and is about to be run, a security warning dialog box will appear (see picture below). At this moment the embedded signature has been verified, the code signing certificate has been verified that it was issued by a trusted CA, and the name of the publisher is displayed to the user. The dialog box asks the user to confirm if it is ok to start the application created by that publisher: Do you want to run this file? Publisher: Mozilla Corporation If the file had not been signed, a different warning would be displayed, asking the user to confirm that the software should be run, even if the publisher is not known: The publisher could not be verified. Are you sure you want to run this software? More technical details are available in an Authenticode whitepaper published by Microsoft.Authenticode in SignServerSince SignServer Enterprise 3.6.3, there is an Authenticode signer for PE files. The signer is configured just like any other signer in SignServer. The only special requirement for this signer is to use a code signing certificate. If your organization already has a CA (for example EJBCA) configured to be trusted by your users, you can use that CA to issue the certificate. Otherwise you could buy a certificate from one of the CAs already trusted by default in Windows.For testing purposes, and also for test environments in general, you could issue the certificate yourself. Just remember to have the extended key usage “Code Signing” set and that you have to install the CA certificate in your test environment.You need to install the CA certificate in your test environment and remember to have the extended key usage set to “Code Signing”. In addition there are a few configuration options that can be applied to specify additional attributes, such as: the name of the application, if time stamping should be used, which service to use etc. Details of configuration options are documented in the SignServer Manual. After configuring and activating the signer, a user can sign code, for example by using the Generic Signing page, specifying the name of the signer and providing the binary to upload: Signer upload form After submitting the file, the signed version (with the embedded signature) is returned: Save signed file In Windows, the signature attached to a specific file can be manually inspected: Right click on the file and choose Properties. Click on the Digital Signatures tab. Select the signature in the Signatures list and click Details. Displaying the signature details on an executable file IntegrationYou can use other interfaces of SignServer (such as the web service interface) to integrate code signing with other systems and applications in a completely transparent way.More informationBasic information on SignServer Enterprise and PrimeKey Code Signing Appliance is available at PrimeKey. [Less]