Encryption basics |
![]() |
![]() |
Written by Administrator | ||||||||||||||||||||||||||||
Friday, 31 August 2001 11:04 | ||||||||||||||||||||||||||||
This document gives a general view about encryption, encryption schemes and how they work. Public Key Distribution SystemPublic key systems, where each corresponded has a pair of keys, can solve both these problems. A key pair is composed of two mathematically related keys: a public key known to everyone and a private key only known to its owner. Diffie-Hellman SchemeUnder the Diffie-Hellman Scheme, a secret key is agreed on and exchanged as follows, using the private and public parts of Werder’s and Bremens Diffie-Hellman keys.
The results of both calculation are the same, and this result serves as the secret key. In this way, a secret key can be agreed on without any secret information being communicated. There is no opportunity for an eavesdropper to determine the secret key. RSA Public KeysIn contrast to a Diffie-Hellman public-private key pair, an RSA public-private key pair is used for encrypting and decrypting messages. A message encrypted with the public key can only be decrypted with the private key and vice versa. Digital SignaturesGenerating a digital signature: A digital signature acts as proof of the sender’s identity and the message’s integrity. Digital signatures can be created using a public key encryption system, such as RSA, as follows:
Verifying a Digital Signature: Upon receiving the message, Bremen can confirm that the message was indeed sent by Werder and that it was not tampered with, as follows:
If they are the same, then Bremen can be sure that:
CertificatesIf Werder and Bremen obtain each other’s public key over an insecure channel, such as the Internet, they must be certain that the keys are genuine. For this reason, there must be a trusted third party, known as a Certificate Authority (CA), from which Werder can reliably obtain Bremens public key, even over an insecure channel (and vice versa).
Werder can then verify the certificate (see above). Werder does not have to obtain Bremens certificate directly from the CA. Bremen can obtain the certificate and send it to anyone who requests it, because a certificate cannot be tampered with. The certificate is “proof” that the message, in this case, Bremens public key is genuine. Werder and Bremen can use each other’s public keys with confidence only if they are certified by certificates from a trusted CA. Encryption SchemesAn encryption scheme consists of the following elements:
Encryption Schemes supported by various vendors
Manual IPSec Encryption SchemeManual IPSec is an encryption and authentication scheme. A security association (SA) is associated with each packet, consisting of:
A 32-bit number, known a the security parameter index (SPI), identifies a specific SA. An SPI is simply an identifier, assigned by correspondents themselves in a particular context, and has no meaning outside the context.
Encryption IP packets are encrypted in accordance with the Encapsulation Security Payload (ESP) standard (RFC 1825, 1827 and 1829). As its name implies, the ESP standard specifies that the original packet is encrypted and then encapsulated into a new, longer packet. There are two modes of performing this encapsulation:
Tunnel Mode: In tunnel mode, the entire packet (including the IP header) is encrypted in accordance with the SA previously decided upon the correspondents. An ESP header containing the SPI and other data is added to the start of the packet, and a new IP header is constructed. The new IP packet consists of:
The new packet is then send on its way. An advantage of this mode is that the destination specified in the new IP header may be different from the one in the original IP header. The picture below shows a paket in IPv4 tunnel mode.
Transport Mode: In the transport mode, the IP header is not encrypted. An ESP header is inserted between the IP header and the transport layer header. The transport layer header and everything following is encrypted. This mode does not increase the length of a packet as much as the tunnel mode does. The encrypted packet must be sent to its original destination.
Authentication If authentication is specified by the SA, then an Authentication header (AH) is added to the packet, in addition to the ESP header (and to the second IP header in Tunnel Mode). The picture below shows a paket in IPv4 transport mode. Manual IPSec has two shortcomings:
Both SKIP and ISAKMP/OAKLEY addresses these shortcomings. SKIP Encryption SchemeSKIP provides a hierarchy of keys that change over time, which are used to encrypt the connection as well as to implement a key management protocol. SKIP also includes ESP and AH, and adds his own header to the packet. The Encryption Key and the Authentication Key are derived from the Session Key, which changes at fixed intervals or when the amount of data encrypted exceeds a given threshold. The newly changed Session Key is communicated by encrypting it with the Kijn key, which changes once every hour. The Kijn key is derived from the Diffie-Hellman shared secret Kij key, using a cryptographic hash function. Each correspondent obtains the public part of the others correspondent’s Diffie-Hellman key from a Certificate Authority, which signs the transmission with its own RSA key. SKIP includes a protocol (Certificate Discovery Protocol) for exchange of public keys. However, this protocol is not supported by FireWall-1, which uses instead a proprietary protocol (RDP = Reliable Data Protocol) for key exchange. ISAKPMP/OAKLEY Encryption SchemeISAKPMP/OAKLEY is a standard for negotiating Security Associations (SA) between two hosts that will be using IPSec, and is the key management scheme that was chosen for IP Version 6. In IP Version 4, ISAKMP/OAKLEY is optional. ISAKPMP/OAKLEY offers improved authentication and Perfect Forward Secrecy (PFS). ISAKPMP/OAKLEY key exchange is divided into two phases:
In this phase, the peers negotiate an ISAKPMP Security Association that will be used for encrypting and authentication Phase Two exchanges. Phase One involves long and CPU-intensive computations, and so is executed infrequentl. The negotiated SA includes the encryption method, authentication method and keys. This SA is used in Phase two negotiation.
Using the SA negotiate in Phase One, the peers negotiating an SA for encrypting the IPSec traffic. Keys can be modified as often as required during a connection’s lifetime by performing Phase Two. Comparison of Encryption Schemes
GlossaryEncryption Encrypting a message modifies (encrypts) its text (plaintext) or „cleartext“ so that the encrypted text (ciphertext) can only be read (decrypted) with the aid of some additional information (e.g. a key) known only to the sender and the intended recipient.
Authentication Authenticating a message verifies the authenticity of both the sender and the message, checking for possible tampering and interference with the communication.
Encrypting a message The simplest way to encrypt a message is by using a secret key, one that both encrypts and decrypts the message. Ensuring this key is very critical, since anyone who knows the key can decrypt and read the message.
Sharing a Secret Key Secret key encryption is simple and fast, but there are two problems associated with its use:
ShortcutsAH = Authentication Header |
||||||||||||||||||||||||||||
Last Updated on Tuesday, 12 June 2012 07:55 |
0 Comments