Internet Security Protocol
Digital certificates extensively on the Internet. This section provides a brief summary on some of the traditional and common uses:
Email Protection
In the physical world, you protect your written correspondence by putting it in an envelope before posting. In the online world, sending an e-mail message is like sending a postcard: it is easy to intercept and read as it travels across the Internet. Instead of risking disclosure of your private e-mails, safeguard them by using encryption and digital signatures.
You can use your free Digital IDs (certificates) provided by Ascertia for testing the secure sending of emails using Outlook Express, Outlook, Lotus Notes etc. Make sure the email address you write in the form to get certificate is the same email address for which you require the certificate from the account you’ll be signing your emails.
How to configure your Signing Certificate ?
Once your email/signing certificate is installed within the Windows certificate store it can be immediately used with PDF Sign&Seal to sign PDF documents. PDF Sign&Seal also enables you to convert Word and other Office documents to PDF so that they can be signed and their rendering on other systems is assured. The digital signature protects the integrity of the information and since it includes the certificate your identity is made known to the recipient. Timestamps can be added to provide independent proof of the date and time of signing. Long term signatures that are good for many year, beyond the life of the certificate can also be provided by PDF Sign&Seal.
Office 2007, Office 2003 and Open Office all provide signing capabilities, although the signing mechanism is not as simple and effective as found within PDFs. PDF signatures are interoperable across a wide range of versions and for this reason once a document is finalised it is recommended that you protect it by converting to PDF and then signing this. Anyone with Reader 7, 8 or 9 can then see and verify the signature.
You can configure your Free certificate to sign emails. In outlook express, click Tools >> Accounts and open an existing account. Select the Security Tab and click Select button in signing certificate section which will open Microsoft Key Store where Certificates and Keys are present. Your Certificate along with the Key should already be present in this key store. (Ascertia Online CA service automatically registers a Certificate along with the key in Microsoft Key Store). If you have obtained a p12 file than you need to import that file by double clicking that file and entering the password.
If you also want to encrypt emails, select a certificate by clicking Select button in Encryption preferences section. In algorithm select either RC2 or DES. If you require more stronger encryption i.e. 3DES or RC2(128 bit) then install Microsoft High Encryption Pack.
After configuring the certificate, create a new message, click button to sign the email or to encrypt. On receiving a digitally signed email, Outlook Express will automatically check whether the contents of email have been tampered or not. (Click here to learn about Cryptography). If email is encrypted with your public key than you require your private key to decrypt the encrypted email.
SSL/TLS for secure e-commerce sites
SSL Certificates
SSL certificates form the basis of an Internet trust infrastructure by allowing Web sites to offer safe, secure information exchange to their customers. SSL server certificates satisfy the need for confidentiality, integrity, authentication, and nonrepudiation. The practical means of implementing PKI and digital signatures are via Web server certificates that enable authentication and SSL encryption.
Introduction
Secure Sockets Layer (SSL), originally developed by Netscape Communications, is an information technology for securely transmitting information over the Internet. The SSL protocol has become the universal standard on the Web for authenticating Web sites to Web browser users, and for encrypting communications between browser users and Web servers.
Server certificates are available from Certificate Authorities (CAs) such as Ascertia, independent third parties such as verisign and thawte etc that issue certificates to individuals, organizations, and Web sites. CAs use verification methods to ensure that certificate users are who they claim to be before issuing them. CA’s own self-signed SSL digital certificates are built into all major browsers and Web servers, including Netscape Communicator and Microsoft Internet Explorer, so that simply installing a digital certificate on a Web server enables SSL capabilities when communicating with Web browsers.
SSL server certificates fulfill two necessary functions to establish e-commerce trust:
- SSL server authentication: Server certificates allow users to confirm a Web server’s identity. Web browsers automatically check that a server’s certificate and public ID are valid and have been issued by a certificate authority (CA)-such as Ascertia which should be included in the list of trusted CAs built into browser software. SSL server authentication is vital for secure e-commerce transactions in which users, for example, is sending credit card numbers over the Web and first wants to verify the receiving server’s identity.
- SSL Client Authentication: SSL-enabled servers can be configured to require client authentication or cryptographic validation by the server of the client's identity. When a server configured this way, the client sends the server both a certificate and a separate piece of digitally signed data to authenticate itself. The server uses the digitally signed data to validate the public key in the certificate and to authenticate the identity the certificate claims to represent. The SSL protocol requires the client to create a digital signature by creating a one-way hash from data generated randomly during the handshake and known only to the client and server. The hash of the data is then encrypted with the private key that corresponds to the public key in the certificate being presented to the server.
SSL encryption
SSL server certificates establish a secure channel that enables all information sent between a user’s Web browser and a Web server to be encrypted by the sending software and decrypted by the receiving software, protecting private information from interception over the Internet. In addition, all data sent over an encrypted SSL connection is protected with a mechanism for detecting tampering: that is, for automatically determining whether the data has been altered in transit. This means that users can confidently send private data, such as credit card numbers, to a Web site, trusting that SSL keeps it private and confidential. Find tools & related information about SSL Encryption.
How SSL Server Certificates Work?
Server IDs take advantage of SSL to work seamlessly between Web sites and visitors’ Web browsers. The SSL protocol uses a combination of asymmetric public key encryption and faster symmetric encryption.
The process begins by establishing an SSL “handshake” allowing the server to authenticate itself to the browser user, and then permitting the server and browser to cooperate in the creation of the symmetric keys used for encryption, decryption, and tamper detection:
- A customer contacts a site and accesses a secured URL: a page secured by a Server ID (indicated by a URL that begins with “https:” instead of just “http:” or by a message from the browser). This might typically be an online order form collecting private information from the customer, such as address, phone number, and credit card number or other payment information.
- The customer’s browser automatically sends the server the browser’s SSL version number, cipher settings, randomly generated data, and other information the server needs to communicate with the client using SSL.
- The server responds, automatically sending the customer’s browser the site’s digital certificate, along with the server’s SSL version number, cipher settings, etc.
- The customer’s browser examines the information contained in the server’s certificate, and verifies that:
- The server certificate is valid and has a valid date
- The CA that issued the server been signed by a trusted CA whose certificate is built into the browser. You can also manually add the trusted CA Certificate at this point
- The issuing CA’s public key, built into the browser, validates the issuer’s digital signature
- The domain name specified by the server certificate matches the server’s actual domain name
- If the server cannot be authenticated, the user is warned that an encrypted, authenticated connection cannot be established
- If the server can be successfully authenticated, the customer’s Web browser generates a unique “session key” to
encrypt all communications with the site using asymmetric encryption.
- The user’s browser encrypts the session key itself with the site’s public key so that only the site can read the session key, and sends it to the server.
- If the server can be successfully authenticated, the customer’s Web browser generates a unique “session key” to encrypt all communications with the site using asymmetric encryption.
- The server decrypts the session key using its own private key.
- The browser sends a message to the server informing it that future messages from the client will be encrypted with the session key.
- The server then sends a message to the client informing it that future messages from the server will be encrypted with the session key.
- An SSL-secured session is now established. SSL then uses symmetric encryption, (which is much faster than asymmetric PKI encryption) to encrypt and decrypt messages within the SSL-secured “pipeline.”
- Once the session is complete, the session key is eliminated.
It all takes only seconds and requires no action by the user. The Netscape Navigator and the Microsoft Internet Explorer browsers have built-in security mechanisms to prevent users from unwittingly submitting their personal information over insecure channels. If a user tries to submit information to an unsecured site (a site without an SSL server certificate), the browsers will, by default, show a warning.
SSL Strengths: 40-bit and 128-bit SSL
SSL comes in two strengths, 40-bit and 128-bit, which refer to the length of the session key generated by every encrypted transaction. The longer the key, the more difficult it is to break the encryption code. 128-bit SSL encryption is the world’s strongest: according to RSA Labs, it would take a trillion years to crack using today’s technology. 128-bit encryption is approximately 3 X 1026 stronger than 40-bit encryption.
Microsoft and Netscape offer two versions of their Web browsers, export and domestic, that enables different levels of encryption depending on the type of SSL server certificate with which the browser is communicating.
40-bit SSL server certificates (such as Ascertia’s Secure Server IDs) enable 40-bit SSL when communicating with export-version Netscape and Microsoft Internet Explorer browsers (used by most people in the U.S. and worldwide), and 128-bit SSL encryption when communicating with domestic-version Microsoft and Netscape browsers.
128-bit SSL server certificates (such as Ascertia’s Global Server IDs) enable 128- bit SSL encryption-the world’s strongest-with both domestic and export versions of Microsoft® and Netscape® browsers.
In order to fully enable 128-bit encryption with a Global Server ID, it’s important to generate the right kind of private key during the process of obtaining a Server ID. An important step in the process is generating a Certificate Signing Request within the Web server software. In generating a CSR, Web server administrators should be careful to select a 1024-bit private key, which enables the Global Server ID to establish 128-bit SSL encryption, rather than a 512-bit private key, which enables only 40-bit encryption.
Netscape users can follow these steps to see what level of encryption is protecting their transactions:
IPSec Secure Networks
The IP Security (IPSec) Protocol is a standards-based method of providing privacy, integrity, and authenticity to information transferred across IP networks. IPSec provides IP network-layer encryption. The two prime functions of IPSec are to ensure data security and data integrity. Security is achieved through data encryption techniques, and integrity through a combination of techniques that authenticate the data sender. Furthermore, IPSec can be used to form ‘tunnels’ through IP networks. In other words, it can make a connection between two computers or networks on the Internet appear as though they’re connected via a private link. This is known as a VPN, a virtual private network. So, in answer to the question, "what is IPSec", it’s a mechanism for providing totally secure virtual private networks across low-cost public networks such as the Internet.
Code Signing
What is Code Signing?
When customers buy software in a store, the source of that software is obvious. Customers can tell who published the software, and they can see whether the package has been opened. These factors enable customers to make decisions about what software to purchase and how much to “trust” those products. When customers download software from the Internet, the most they see is a message warning them about the dangers of using the software. The Internet lacks the subtle information provided by packaging, shelf space, and shrink-wrap. Without any assurance of the software’s integrity, and without knowing who published the software, it’s difficult for customers to know how much to trust software downloaded from the Internet.
The solution to these issues is Sun Java Object Signing coupled with Ascertia® Code Signing Digital IDs. Object Signing, through the use of digital signatures, enables software developers to include information about themselves and their code with their software.
When customers download software signed with a Sun Java Code Signing Digital ID issued by Ascertia, they can be assured of:
- Content Source: End users can confirm that the software really comes from the publisher who signed it.
- Content Integrity: End users can verify that the software has not been altered or corrupted since it was signed.
Users benefit from this software accountability because they know who published the software and that the code hasn’t been tampered with. In the extreme case that software performs unacceptable or malicious activity on their computers; users can also pursue recourse against the publisher. This accountability and potential recourse serve as a strong deterrent to the distribution of harmful code. Developers and Web masters benefit from Object Signing because it builds trust in their names and makes it more difficult to falsify their products. By signing their code, developers build a trusted relationship with users, who learn they can download software signed by that publisher or Web site with confidence. With Sun Java Signing, developers can create exciting Web pages using signed Java applets, plug-ins, or other executables. And users can make educated decisions about what software they want to download.
Who Needs a Code Signing Digital ID?
Any software publisher planning to distribute code or content over the Internet or through an extranet risks impersonation and tampering. Ascertia Code Signing Digital IDs for Sun Java Signing protect against these hazards.
Ascertia offers Code Signing Digital IDs designed for commercial software developers: companies and other organizations that publish software. This class of Digital ID provides assurance regarding an organization’s identity and legitimacy, much like a business license, and is designed to represent the level of assurance provided today by retail channels for software.
How Does Object Signing Work with Ascertia Code Signing Digital IDs?
Sun Java Signing relies on industry-standard cryptography techniques such as X.509 v3 Code Signing IDs and PKCS #7 and #10 signature standards. These well proven cryptography protocols ensure a robust implementation of code signing technology.
Object Signing uses digital signature technology to assure users of the origin and integrity of software. In digital signatures, the private key generates the signature and the corresponding public key validates it. To save time, the Object Signing protocols use a cryptographic digest, which is a one-way hash of the document. Note: Java Runtime Environment (JRE) version 1.3 or newer must be installed on the end user’s machine.
The Code Signing Process
- Publisher creates code
- Publisher obtains a Sun Java Code Signing Digital ID from Ascertia.
- Using the Java 2 Software Development Kit, the publisher:
- Creates a hash of the code, using an algorithm such as MD5 or SHA
- Encrypts the hash using their private key
- Creates a package containing the code, the encrypted hash, and the publisher’s Code Signing Digital ID
- The end-user’s Java Runtime Environment (JRE) encounters the package.
- The end-user’s JRE examines the publisher’s Code Signing Digital ID. Using the Ascertia root public key that should be embedded in the end-user JRE trusted root store, the end-user JRE verifies the authenticity of the Code Signing Digital ID (which is itself signed by the Ascertia root private key). If Ascertia root public key is not present already in JRE trusted root store, you have to manually add the certificate to the trusted root store.
- Using the publisher’s public key contained within the publisher’s Digital ID, the end-user JRE decrypts the signed hash.
- The end-user JRE runs the code through the same hashing algorithm as the publisher, creating a new hash.
- The end-user JRE compares the two hashes. If they are identical, the JRE sends a message stating that the content has been verified by Ascertia. The end user is assured that the code was signed by the publisher identified in the Digital ID and that the code hasn’t been altered since it was signed.
The entire process is transparent to end users, who see only a message that the content was signed by its publisher and verified by Ascertia.
The Six Steps to Signing Code
These instructions provide an overview of obtaining and using Sun Java Signing and a Code Signing Digital ID from Ascertia.
Step 1: Download the Java 2 Software Development Kit (SDK).
The Java2 SDK for the Solaris SPARC/x86, Linux86, and Microsoft Windows platforms is available free of charge from java.sun.com. You will be using the following tools to apply for your Code Signing Digital ID and sign your code: keytool, jar, and jarsigner.
Step 2: Generate a public/private key pair.
Enter the following code, specifying an alias for your keystore, to generate a public/private key pair.
C:>keytool -genkey -keyalg rsa -alias MyCert
In this string, the keystore alias is MyCert. Keytool responds with prompts to enter a password for your keystore, your name, organization, and address information. The public/private key pair generated by keytool is saved to your keystore and will be used to sign Java Applets and Applications.
Note: Your private key is never sent to Ascertia, so if you lose it, you will be unable to sign code.
Step 3: Generate a Code Signing Digital ID Signing Request (CSR).
Enter the following code to generate a CSR:
C:>keytool -certreq -alias MyCert
In this string, keytool is requested to create a CSR for the key pair in the keystore MyCert. After prompting you to enter the password for your keystore, keytool will generate a CSR.
-----BEGIN NEW CODE SIGNING ID REQUEST-----
MIIBtjCCAR8CAQAwdjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRIwE
AYDVQQHEwlDdXBlcnRpbm8xGTAXBgNVBAoTEFN1biBNaWNyb3N5c3RlbX
MxFjAUBgNVBAsTDUphdmEgU29mdHdhcmUxEzARBgNVBAMTClN0YW5sZXk
gSG8wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALTgU8PovA4y59eb
oPjY65BwCSc/zPqtOZKJlaW4WP+UhmebE+T2Mho7P5zXjGf7elo3tV5uI
3vzgGfnhgpf73EoMow8EJhly4w/YsXKqeJEqqvNogzAD+qUv7Ld6dLOv0
CO5qvpmBAO6mfaI1XAgx/4xU/6009jVQe0TgIoocB5AgMBAAGgADANBgk
qhkiG9w0BAQQFAAOBgQAWmLrkifKiUYtd4ykhBtPWSwW/IKkgyfIuNMML
dF1DH8neSnXf3ZLI32f2yXvs7u3/xn6chnTXh4HYCJoGYOAbB3WNbAoQR
i6u6TLLOvgv9pMNUo6v1qB0xly1faizjimVYBwLhOenkA3Bw7S8UIVfdv
84cO9dFUGcr/Pfrl3GtQ==
-----END NEW CODE SIGNING ID REQUEST-----
This string is an example of a CSR generated using keytool. A CSR contains a copy of the requestor’s public key and a hash of the data entered in step 2 signed with the requestor’s private key.
Copy the CSR and paste it into the Ascertia PKCS10 Free Cert section
When your request is approved, Ascertia will issue you certificate.
Upon receipt, the attached Code Signing Digital ID is saved to a file on your computer.
A Code Signing Digital ID is a “trust path” or “chain” back to the Ascertia root certificate. This “trust path” allows your code to be validated on any standard JRE without installing any additional files.
Note: Ascertia takes a number of steps to verify your identity. For commercial publishers, Ascertia does a considerable amount of background checking.
Step 4: Import your Sun Java Signing Code Signing Digital ID.
Enter the following code, with the path to your Code Signing Digital ID, to import the chain into your keystore.
C:>keytool -import -alias MyCert -file TestNew.cer
In this string, keytool is requested to import the Code Signing Digital ID “TestNew.cer” into the keystore MyCert.
Step 5: Bundle your applet into a JAR file.
Use jar to bundle your Applets or applications as a JAR file.
C:>jar cvf C:\TestApplet.jar
This string creates a JAR file C:\TestApplet.jar. The JAR file contains all the files under the current directory and its sub-directories.
Jar responds with:
added manifest
adding: TestApplet.class (in = 94208) (out = 20103)(deflated 78%)
adding: TestHelper.class (in = 16384) (out= 779)(deflated 95%)
Step 6: Sign your applet.
Use jarsigner to sign the JAR file, using the private key you saved in your keystore.
C:>jarsigner C:\TestApplet.jar MyCert
At the prompt, enter the password to your keystore. Jarsigner hashes your Applet or Application, and stores the hash in the JAR file created in step 5 with a copy of your Code Signing Digital ID. Verify the output of your signed JAR file.
C:>jarsigner -verify -verbose -certs
This string verifies that the files have been saved to the JAR file and that the signature is correct. When the signed JAR file is downloaded, the Java Runtime Environment will display your Digital ID to the user. If the file is tampered with in any way after it has been signed, the user will be notified and given the option of refusing installation. For more in-depth instructions on the use of the Java 2 Software Development Kit, please see the Java? 2 Platform, Standard Edition, v 1.3 Documentation, available at http://www.javasoft.com/j2se/1.3/docs.html .
Conclusion
With Sun Java Object Signing and a Ascertia Code Signing ID, your code will be as safe and trustworthy to your customers as it would be if you shrink-wrapped it and sold it off a store shelf. For more information about Ascertia Commercial Code Signing Digital IDs for Sun Java Signing, including pricing, availability, and Frequently Asked Questions, please contact sales@ascertia.com