|
Encryption - What is it? Encryption means disguising plain text so that it is unreadable. When plain text is in this encrypted state it is called 'ciphertext'. Making sense of this ciphertext is done using decryption. The process: Encryption of plain text -> Ciphertext ->Decryption to plain text. When you decide to encrypt data e.g. an email message, you are encoding it so that only it's intended recipient can decrypt it. It means that if the email message is intercepted, it cannot be read.
Why should I encrypt my emails? When we send email messages, their journey can be extremely complicated. Each message may pass through many servers, routers etc. An email message may travel half way round the world before it is received by its intended recipient. With such exposure, any interception could occur along its route. It is therefore vital that information contained within your emails is unreadable. It is important to keep information like credit card details, bank details and so on secure. If left unsecure, your email information can fall prey to 'Email Sniffers'.
What is an Email Sniffer? Email Sniffers capture data being sent over the Internet. Another way of putting it is 'electronic eavesdropping'. They have a sophisticated set of tools which they use to spy on your information. They can receive copies of all your messages.
What damage can an Email Sniffer do? Once they have received your information they are in a position to carefully extract what details they find of interest to them e.g. credit card numbers, email addresses (for sending Spam), confidential and sentitive business or personal information. They can also decide to tamper with your emails and send damaging information to those addresses you send emails to.
Public and Private Keys (assymmetric cryptography): Before we start discussing the different secure data transfer methods it is important to understand some definitions.
No matter how you look at it, identification is an essential part of everyday life. Employees wear identification badges so that security guards can recognise them. We carry passports, driving licenses etc. to identify us. Showing some form of identification builds trust. Likewise, it's no different on the Internet. When it comes to identifying people, there are a number of ways: - Passwords - Access Cards - Biometrics - fingerprints, DNA etc.
However, all of these methods can be improved by using Digital Signatures. A digital signature system creates two keys: Private Key: Used when decrypting and used to Digitally Sign emails etc. Public Key: Used when encrypting emails/public key encryption and used to verify the Digital Signature. Your two keys work as a pair. Anything locked with one key must be unlocked with the other.
The two keys are mathematically dependent on eachother, but it is a requirement of the algorithm that one key can be computed from the other key at most in one direction, while the other direction must be computationally infeasable. This property allows the creation of one key public while the other key must be kept secret.
How exactly do Public and Private Keys work? First Some Notes: There is a difference between an asymmetric (aka "public") crypto and a digital signature system: it MIGHT be combined in one crypto system (and mostly is) or it might be a separate operation. And yes, both do use a pair of keys but they need not necessarily be the same pair.
You may use asymmetric encryption without any digital signature. This will fullfill all requirements of secrecy for scrambling the message, with one weakness left: there is no guarantee, that the originator of the message is REALLY he who says he is (mostly the content will perfectly identify the sender).
Let's use an example:
Alice is the owner of One Public Key and One Private Key. Alice knows that it doesn't matter who knows her Public Key (hence the name), but she keeps her Private Key to herself.
What happens if her friend Bob wants to send her an email? 1. Bob will encrypt the email using Alices Public Key and send her the encrypted email 2. Alice will use her Private Key to decrypt it. Note: Anyone can look at Alice's encrypted message, but cannot read it without her Private Key.
In this scenario Bob has to assume that he is actually talking to the real Alice as there is no digital signature involved. If Alice and Bob both use digital signatures to sign their messages then the authenticity of their communication can be verified via a CA (Certification Authority).
LESSONS: The greater the number of people who have your public key the better. However, nobody should get hold of your Private Key, otherwise they could use it to forget your signature on documents etc.
What is a Certification Authority (CA)? At the time of verifying a digital signature the verifier must be sure that the public key which he uses for the verification of the signature is the public key of the supposed signer. Public keys can be certified through a third party whom both the signer and verifier can trust. This third party is called a Certification Authority (CA).
What is a Digital Certificate? In essence, a Digital Certificate verifies that a particular public key is owned by a particular individual, company, server etc. The Certificate verifies the Digital Signature. Digital signatures are essential in electronic commerce. They act as that electronic stamp of authenticity. The Certificate is signed by the certification authority's own private key. A Digital Certificate contains the following information.
|
Certificate Key Components |
| Version |
The verion of the x.509 standard to which the certificate conforms. |
| Serial Number |
The Certificate Serial Number. This number is unique. |
| Algorithm Identifier |
The algorithm used to sign the certificate. |
| Issuer |
The name and location details of the body that is issuing the certificate e.g. Verisign International. |
| Validity |
Holds the certificate validation dates and time. Once the certificate falls outside of this date/time range, it is considered invalid and will not be accepted when negotiating communicatons. |
| Subject |
Holds the name of the individual and location details to which the private key is being certified. |
| Subject's Public Key |
Holds the subject's public key. |
| Issuer Unique Identifier |
Optional. Accommodates a situation where perhaps two issuers have the same name. This field would then be used to distinguish between them. |
| Subject Unique Identifier |
Optional. Accommodates a situation where perhaps two individuals in the same company have the same name. This field would then be used to distinguish between them. |
| Extensions |
The issuer can add private information here. |
| Signature |
Holds the algorithm identifier as a secure representation of all the other fields in the certificate and a digital signature of this representation. |
What are Cipher Suites SSL protocol supports the use of different cryptographic algorithms (ciphers). These ciphers can be used when authenticating the server and client to each other, transmitting certificates, and establishing session keys. Clients and servers may support different cipher suites. Examples of the different types of cipher suites include: DES Data Encryption Standard, an encryption algorithm used by the U.S. Government. DSA Digital Signature Algorithm, part of the digital authentication standard used by the U.S. Government. KEA Key Exchange Algorithm, an algorithm used for key exchange by the U.S. Government. MD5 Message Digest algorithm developed by Rivest. RSA A public-key algorithm for both encryption and authentication. Developed by Rivest, Shamir, and Adleman. DH Diffie Hellman.
SSL - What is it? SSL stands for Secure Socket Layer. It is developed by Netscape. SSL is a protocol that is used to ensure that communications between the Client and Server are encrypted when transferring information. When the Client and Server communicate they use SSL messages. SSL server authentication: allows the client to confirm the server's identity. The client checks if the server's certificate and public key are valid and have been issued by a certificate authority (CA) listed in the client's list of trusted CA's. SSL client authentication: allows the server to confirm the user's identity. The Server can check if the client's certificate and public key are valid and have been issued by a certificate authority (CA) listed in the server's list of trusted CA's.
SSL Handshake - What is it? SSL Handshake allows: - server authentication to the client. - the client and the server to decide upon which cryptographic algorithms or cipher suites to use e.g. RSA, DH etc. - the use of public key encryption to generate shared secrets. - generation of an encrypted SSL connection.
The following includes some of the messages that are used in the establishment of encrypted communications between client and server:
|
CLIENT |
< < < < > > > > |
SERVER |
| ClientHello |
---------------------> |
|
| |
<--------------------- |
ServerHello |
| |
<--------------------- |
Certificate |
| |
<--------------------- |
ServerKeyExchange |
| |
<--------------------- |
ServerHelloDone |
| Certificate |
---------------------> |
|
| ClientKeyExchange |
---------------------> |
|
| CertificateVerify |
---------------------> |
|
| ChangeCipherSpec |
---------------------> |
|
| Finished |
---------------------> |
|
| |
<--------------------- |
ChangeCipherSpec |
| |
<--------------------- |
Finished |
ClientHello A ClientHello message is sent to the server (from the Client) outlining the type of Cipher suites (security options) it needs and what security options it can handle.
ServerHello A ServerHello message is sent to the client (from the server) telling it what type of security options will be used in the communication process.
Certificate The Certificate message is sent from the Server to the Client and holds the server's public key certificate.
ServerKeyExchange A ServerKeyExchange message is sent to the Client (from the Server) holding the cryptographic keys that are necessary for a secure communication process. The Cryptgraphic key exchanged here is the Server's Public Key. The client will use this public key to encrypt data for transmission. The server will use its private key to decrypt the data. IMPORTANT: The server at this point could send its Certificate to the client instead of the ServerKeyExchange message. The client can check that the server's certificate and public key are valid and issued by a certificate authority listed in the servers list of trusted CA's.
ServerHelloDone A ServerHelloDone message is sent to the Client (from the server) indicating that all requests have been dealt with for establishing the communication process.
Certificate The Certificate message is sent from the Client to the Server and holds the client's public key certificate.
ClientKeyExchange A ClientKeyExcange message is sent to the server (from the client) holding the cryptographic keys that are necessary for a secure communication process. The Cryptgraphic key exchanged here is the Client's Public Key. The client encrypts its ClientKeyExchange information using the servers' public key. This allows the client to verify that the other party (server) possesses the correct Private key to decrypt the data. IMPORTANT: The client can send the server its certificate. The server can check that the client's certificate and public key are valid and issued by a certificate authority listed in the servers list of trusted CA's.
CertificateVerify The CertificateVerify message is sent from the Client to the Server. It uses the Client's private key to sign session information and the server uses the client's public key to verify client identity.
ChangeCipherSpec A ChangeCipherSpec message is sent to the server (from the client) indicating that they should proceed with communications using a secure process.
Finished A Finished message is sent to the server (from the client) indicating that negotiations are complete and that secure communications have been established.
ChangeCipherSpec A ChangeCipherSpec message is sent to the client (from the server) indicating that they should proceed with communications using a secure process.
Finished A Finished message is sent to the client (from the server) indicating that negotiations are complete and that secure communications have been established. Top
TLS - What is it? TLS stands for Transport Layer Security. The Internet Engineering Task Force (IETF), with the consent of Netscape, have made some changes to the SSL Protocol and brought it to a new level. This is now referred to as TLS Protocol.
TLS has additional alerts and some of them are listed as follows: UnknownCA The Server indicates that the Certificate Authority could not be identified or trusted.
Insufficient Security The Server indicates that it requires Cipher suites (security codes) that are more secure that what is supported by the client.
DecryptionFailed The Server indicates that the message it has decrypted is invalid e.g. it may have had invalid padding etc.
RecordOverflow The Server indicates that the decrypted message is greater than 2 to the power of 14 plus 2048 bytes.
User Comments
Encryption
|
|
There are no user comments for this topic.
|
|
|
|